D/Phobos Style guide
我刚刚开始查看 phobos 源代码，其中散布着几种不同的样式并注释掉了代码。
web 端的风格指南很小，我只找到了 2006 年的断链和 2004 年的另一个...
是否有更新、更全面的指南可用？
PS：最初是在 D.learn 新闻组问的，但由于我没有得到任何答案，我想我可能会在这里尝试，即使它可能是在黑暗中拍摄
现有的任何指南都已过时，不应再存在。我不相信有任何类型的 D 风格指南被认为是有效的，我不认为 Walter Bright、Andrei Alexandrescu 等人希望有一个。另外，我记得，在 C 编码标准：101 条规则、指南和最佳实践中，Herb Sutter 和 Andrei 说样式指南是一个坏主意(或者至少那些非常具体的指南是一个坏主意)，但我不得不拿出书来确定他们说的是什么。所以我很怀疑Phobos(由Andrei负责)会有任何风格指南。我当然不知道。可能有一些格式化代码进入 Phobos 的指导方针(比如让你的代码看起来与模块的其余部分相似或类似)，但像 Andrei 或其他 Phobos 开发人员之一这样的人必须回答这个问题。当然，大约有 15 位不同的开发人员在 Phobos 上工作，如果没有强制的样式指南，您肯定会在代码中获得几种不同的样式。
所以，我不相信对于 D 或 Phobos 真的有任何推荐的编码风格。据我了解，D 背后的主要人物并不是特别支持风格指南，他们当然也没有推动过风格指南。所以，现在真的没有，我也不指望将来会有。
编辑：好的，我去查了一下 Herb Sutter 和 Anderi Alexandrescu 在 C 编码标准：101 条规则、指南和最佳实践中所说的内容。与其说他们反对编码标准，不如说他们反对那些强制执行个人品味或过时做法的特别严格的标准。我不打算在这里引用整件事(这是一本好书，无论如何你应该把它捡起来)，但这里有一些要点。
- 不要指定缩进多少，而是缩进以显示结构。
- 不要强制执行特定的行长，但要保持行长可读。
- 不要过度立法命名，但要给我们一个一致的命名约定。
- 不要指定注释样式(除非工具将某些样式提取到文档中)，但要编写有用的注释。
他们给出的一些例子是
- 大括号的位置应该无关紧要，但它应该是一致的和可读的。
- 在空格与制表符上，他们似乎并不关心编码标准是否对此有任何说明。
- 他们反对 C 中的匈牙利符号，但认为它在类型安全性较低的语言中可能很有价值。
- 他们完全反对强制在函数中有一个返回语句。
无论如何，他们确实认为源文件中的格式应该是一致的。显然，Phobos 在这一点上并不一定坚持这一点，但 Andrei 确实在新闻组中提出了一些通常坚持并正在考虑可能执行其中一些的惯例(实际帖子存档在这里)。
但是，虽然 Phobos 是开源的，任何人都可以自由提交补丁，但请记住，它是供公众使用的 API。只有 Phobos 开发人员需要查看代码(至少在文档适当完整的情况下)——当然，他们是唯一将直接处理代码的人——因此不需要公开列出编码标准，即使他们使用一种。看起来他们可以使用更多的一致性，并且他们可能正在为此努力，但是对于第 3 方来说，要做的就是使其更具可读性。没有其他人真正需要知道该标准实际上是什么(尽管如果您按照标准查看了足够多的代码，您至少可以或多或少地弄清楚该标准所说的内容)。
至于 D ，有一些约定被认为是好的做法(例如通常使用
事情已经发生了很大的变化，我认为我应该重新回答这个问题。您可以在此处查看当前的 D 风格指南，它现在是最新的。它有一些关于格式的规则(例如，没有制表符，每级缩进是 4 个空格)，但几乎所有规则都是关于命名约定的(例如，类型名称应该使用 PascalCase，而变量和函数应该使用 camelCase )。因此，重点是 API 应该是什么样子，而不是代码应该如何格式化。正如我在之前的回答中详述的那样，Phobos 开发人员绝不会尝试为整个 D 强制采用官方格式样式。事实上，有很多 D 程序员甚至不遵循官方风格指南中的命名约定。
未来可能会对 Phobos 本身实施更严格的格式指南(已经讨论过但从未完成)，以便让提交者更清楚他们应该遵循什么风格并避免争论代码格式化(自从我们迁移到 github 并且提交者的数量已经显着增加后，这成为一个更大的问题)，但在这一点上，它主要归结为确保模块中的代码格式一致。但同样，即使对 Phobos 规定了更严格的格式规则，这也将是 Phobos 特有的，而不是针对整个 D 社区的。对于应该如何格式化代码以使社区范围的格式化标准能够正常工作，有太多不同的意见。