Dart 编码风格指南

后一篇:
作者信息: API Naming Guide
作者链接: https://www.dartlang.org/articles/api-naming-guide/

本指南由 Bob Nystrom 与 2011 年八月编写(2015 年二月更新)

当我们构建好了 Dart 编码系统时,使用一致的编码风格是很重要的。本教程是精心编写的 Dart 风格指南,旨在帮助大家了解该语言独有的特性,并且让 Dart 开发者之间的协作更加容易。

也许在本教程中有些内容您并不认同。即使作为作者,也有一些事情是我所不认同的。所以,我希望各位读者能够先认同一点,那就是通常情况下,一致性远比个人喜好要有价值的多。

对于很多东西,比如 Dart 来说,教程并不是死板的,这一点一定要牢记在心。随着语言的发展,我们将会从中吸取许多经验,而我们的编码风格也将随之变化。这也就是必然会出现没有遵循最新风格的代码,也可能是由于指南中存在二义性的部分或者没有涉及的地方而使得读者按照自己的喜好编写了代码。这些疏漏之处还请读者们和我们一起承担,当 Dart 及其库逐渐稳定的时候我们的指南也会变得更好。

你也可以看一下相关文档:

如何阅读本指南

本指南按照从宏观到微观的顺序大致分为了几个部分。每个部分又包含一系列的指导准则。每个准则都包括下面这些词:

  • - 该准则形容了应始终遵循的做法。你几乎找不到理由不去遵循这些做法。
  • 不要做 - 这些准则则是相反的:该部分说明的内容往往不是个好的选择。看完本指南,你将会注意到这块有不少的内容。其他语言中的这类准则有助于避免因时间推移而出现的错误。Dart 语言是全新的一门语言,使用 Dart 时我们可以直接修复这些陷阱而不需要总是小心翼翼的。
  • 最好 - 这些是你应该遵循的做法。但是在某些情况下采取其他做法将会更好。你只需要理解这些暗示就好,当你实际动手时,应该忽略这些准则。
  • 避免 - 这是和“最好”相对的:一般情况下你不应该做的事,但是在很少的情况下它又是一种很好的选择。
  • 考虑 - 这些可能是你不希望遵循的,对于这些准则,你可以考虑一下具体情况、一些先例甚至是你个人的喜好再决定要不要遵循。

看完上面这些以后,你可能感觉如果没有一定的准备就会被编码风格打败。不用担心,本指南中的大多数准则都是常识,而我们都是明智的人。我们最终的目标,就是写出优美的、高可读性、高维护性的代码。

后一篇: