• 根据惯例对文件实现良好命名。请参阅[url= 在适当的文件夹中。考虑因素包括目的和功能区域。 由功能分离组织，而不是按文
  • 避免依赖null和之间的区别undefined。这样做往往会导致代码脆弱。在对它们中的任何一个进行相等性检查时使用非强制相等（==）null。避免使用两者来表示不同类型的“无值”情况，例如“unknown field”与“no value for today”。 谨防用真假检查零。如果存在数字，则通
  • 每次提交的是一个合乎逻辑的工作成功。将每个功能，错误和重构与其他功能分开。这使得历史更加有用，并鼓励采用有组织的方式开展工作。如果您需要在处理功能时修复错误，请考虑使用源代码控制功能（如[url= icon
  • 避免无意义的注释评论，不添加任何价值。如果通过阅读代码可以清楚地看到某些内容，则评论只会增加噪音。 考虑是否可以改进代码，以便不再需要注释。通过改进命名，重构（例如，提取函数）或引入解释变量，通常可以解释解释代码正在做什么以及有时为什么的注释。 考虑一个单元测试是否会更好的沟通。构造良好和命名的 icon
  • 任何Java开发人员都需要强制阅读 [url= Java[/url] ，并且还强烈推荐[url= icon
  • CSS也是代码。本指南中其他主题的项目适用。它需要代码审查，并且需要进行自动和手动质量检查和规则 - 就像任何其他应用程序代码一样。可怜的CSS很难修改和扩展，并且很难改变或重构应用程序。 使CSS接近其样式的组件代码。阅读：[url= icon
  • 在方法接口的域中抛出异常。这可以避免破坏抽象或应用程序层。例如，DAO不应抛出HTTP异常，也不应传播JDBC异常。可以捕获异常并将其包装在更合适的位置以便于实现此目的。 要么用日志记录异常，要么抛出它们 - 通常不是两者。抛出的异常将在某种程度上被捕获; 如果较低级别的投掷者无法处理异常，则可能不 icon
  • 可读性和可维护性的一般规则： 尽量拆分长/大的东西。这包括文件，文件夹，方法和模板。拥有许多行/文件/部分表明某些事情做了太多事情，这使得理解，维护和适应变得困难。寻找可以进行拆分的抽象和责任。 避免添加偷渡性代码。要想想新代码的目标是应该去哪里。通过在现有方法/类中添加几行/方法，有时可以很方便地 icon
  • 一般规则： 避免在构造函数中做大量工作。这通常会限制构建和初始化类的灵活性，通常会导致难以测试。 谨防过度类似的条件。它们可能是缺失或不合适的抽象的标志，或者是改进设计的一般需求。 处理边缘情况。请注意仅考虑最常见的情况。示例包括无数据，无效数据，边界条件，错误和空值（如果适用）。 避免 icon
  • 体面编码就是编写更好代码的简明指南，这是一份指南/清单，可帮助人们提高编码和代码审查。 计算机科学中只有两件事：缓存失效和命名 - 菲尔卡尔顿 每个东西都有一个名称，每个名称只用于一件事。使用多个词来表示相同的事物，或者同一个词来表示不同的事物，会浪费认知的努力并且可能导致混淆。这不仅适用于代码 icon