[Javascript] 编程实践之1: Google的Javascript代码风格8：一些策略

8 一些策略

8.1 Google样式指南未明确指出的问题：请保持一致性！

对于本规范未明确解决的任何样式问题，请优先执行同一文件中其他代码已在执行的操作。 如果这样不能解决问题，请考虑模拟同一包中的其他文件。

8.2 编译器警告

8.2.1 使用标准警告集

项目应尽可能使用--warning_level = VERBOSE。

8.2.2 如何处理警告

在执行任何操作之前，请确保您完全了解警告所告诉的内容。 如果您不确定为什么会出现警告，请寻求帮助。

了解警告后，请按顺序尝试以下解决方案：

1. 首先，修复它或解决它。 尽力尝试实际解决警告，或者找到另一种方法来完成完全避免这种情况的任务。
2. 否则，请确定是否为错误警报。 如果您确信警告无效并且代码实际上是安全且正确的，请添加注释以使读者相信这一事实，并应用@suppress批注。
3. 否则，留下待办事项注释。 这是不得已的方法。 如果这样做，请勿抑制警告。 警告应该是可见的，直到可以妥善处理。

8.2.3 在最窄的合理范围内禁止警告

警告被抑制在最窄的合理范围内，通常是单个局部变量或很小的方法。 通常仅出于该原因才提取变量或方法。

例：

/** @suppress {uselessCode} Unrecognized 'use asm' declaration */
function fn() {
  'use asm';
  return 0;
}

即使对一个class进行大量压制，也比使整个class对此类警告视而不见要好。

8.3 弃用

使用@deprecated批注标记不赞成使用的方法，类或接口。 弃用评论必须包含简单明了的指导，以便人们修复呼叫站点。

8.4 代码不是Google风格

您偶尔会在代码库中遇到格式不正确的文件。 这些可能来自收购，也可能是在Google Style就某个问题采取立场之前写的，或者可能由于其他任何原因而不是Google Style。

8.4.1 重新格式化已有代码

更新现有代码的样式时，请遵循以下准则。

1. 不需要更改所有现有代码即可满足当前的样式准则。 重新格式化现有代码是代码搅动和一致性之间的折衷。 样式规则会随着时间的流逝而发展，而为了保持合规性而进行的此类调整会造成不必要的流失。 但是，如果对文件进行了重大更改，则预计该文件将采用Google样式。
2. 注意不要让机会主义的风格修正混淆CL的重点。 如果您发现自己进行了很多样式更改，而这些样式更改对于CL的中心重点而言并不重要，则可以将这些更改推广到单独的CL中。

8.4.2 新加入的代码：请遵照Google风格

无论同一软件包中其他文件的样式选择如何，全新文件都使用Google样式。

当将新代码添加到非Google风格的文件中时，建议首先重新格式化现有代码，但要遵循8.4.1 重新格式化已有代码。

如果未重新格式化，则新代码应与同一文件中的现有代码尽可能一致，但不得违反样式指南。

8.5 本地风格规则

团队和项目可以采用本文档中未提及的其他样式规则，但必须接受清除更改可能不遵守这些附加规则，并且不得由于违反任何其他规则而阻止此类清除更改。 提防毫无用处的过度规则。 样式指南并不试图在每种可能的情况下都定义样式，您也不应该。

8.6 生成的代码：大部分豁免

由构建过程生成的源代码不需要使用Google样式。 但是，将从手写源代码引用的任何生成的标识符必须遵循命名要求。 作为特殊例外，此类标识符允许包含下划线，这可能有助于避免与手写标识符发生冲突。