策略
一致性
对于本规范未明确规定的任何风格问题，按照同一文件中其他代码已经使用的方式（“保持一致”）。如果这仍然无法解决问题，考虑模仿同一目录中其他文件的方式。
全新的文件必须使用 Google 风格，无论同一包中其他文件的风格选择如何。在向非 Google 风格的文件添加新代码时，建议先重新格式化现有代码，具体参见下文的建议。如果不进行此重新格式化，则新代码应该尽可能与同一文件中的现有代码保持一致，但禁止违反风格指南。
重新格式化现有代码
你偶尔会遇到代码库中不符合 Google 风格的文件。这些文件可能来自收购，或者在 Google 风格对某些问题做出规定之前编写的，或者因其他原因不符合 Google 风格。
更新现有代码的风格时，请遵循以下指导原则。
- 不要求更改所有现有代码以符合当前风格指南。重新格式化现有代码是代码变动和一致性之间的权衡。风格规则会随时间演变，为了维持合规而进行的这类调整会产生不必要的代码变动。然而，如果对文件进行了重大更改，则期望该文件符合 Google 风格。
- 注意不要让随机的风格修复模糊了 CL 的焦点。如果你发现自己做了很多与 CL 核心焦点无关的风格更改，请将这些更改提升到单独的 CL 中。
弃用
使用 @deprecated JSDoc
注解标记已弃用的方法、类或接口。弃用注释必须包含简单、清晰的说明，指导人们修复其调用处。
生成的代码：基本豁免
由构建过程生成的源代码不要求符合 Google 风格。然而，任何将从手写源代码引用的生成标识符都必须遵循命名要求。作为特殊例外，此类标识符允许包含下划线，这可以帮助避免与手写标识符的冲突。
风格指南目标
一般来说，工程师通常最了解他们的代码需要什么，因此如果有多个选项且选择取决于具体情况，我们应该让决定在本地做出。所以默认的答案应该是“不做规定”。
以下几点是例外，也是我们制定一些全局规则的原因。请根据以下标准评估你的风格指南提案：
-
代码应避免已知会导致问题的模式，特别是对于该语言的新手。
-
跨项目的代码应在无关的变化方面保持一致。
当两个选项在表面上等价时，我们应该考虑选择一个，这样我们就不会无缘无故地产生分歧，避免在代码审查中进行无意义的争论。
示例：
- 名称的大小写风格。
x as T语法与等效的<T>x语法（被禁止）。Array<[number, number]>与[number, number][]。
-
代码应具有长期可维护性。
代码的存活时间通常比原作者在其上工作的时间长，TypeScript 团队必须让所有 Google 的代码在未来继续工作。
示例：
- 我们使用软件自动化代码更改，因此代码会被自动格式化，以便软件容易满足空白规则。
- 我们要求一组统一的编译器标志，这样给定的 TS 库可以在假定特定标志集的情况下编写，用户可以始终安全地使用共享库。
- 代码必须导入它使用的库（“strict deps”），这样依赖项中的重构不会改变其用户的依赖关系。
- 我们要求用户编写测试。没有测试，我们无法确信我们对语言所做的更改不会破坏用户。
-
代码审查者应专注于提高代码质量，而不是执行任意规则。
如果可以将你的规则实现为自动化检查，这通常是一个好兆头。这也支持原则 3。
如果它真的不那么重要——如果它是语言的一个晦涩角落，或者它避免了一个不太可能发生的 bug——那它可能不值得纳入。
命名空间导入(Namespace Import)通常被称为"模块导入"
<a href="#fnref1" rev="footnote">↩︎</a>
命名导入(Named
Import)有时被称为"解构导入"，因为它们使用了与解构赋值类似的语法。
<a href="#fnref2" rev="footnote">↩︎</a>