我刚刚开始查看 phobos 源代码,其中散布着几种不同的样式并注释掉了代码。
网页端的风格指南很小,我只找到了2006年的断链和2004年的另一个...
是否有更新、更全面的指南可用?
PS:最初是在 D.learn 新闻组问的,但由于我没有得到任何答案,我想我可能会在这里尝试,即使它可能是在黑暗中拍摄
我刚刚开始查看 phobos 源代码,其中散布着几种不同的样式并注释掉了代码。
网页端的风格指南很小,我只找到了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++ Coding Standards: 101 Rules, Guidelines, and Best Practices中所说的话。并不是说他们反对编码标准,而是反对那些强制执行个人品味或过时做法的特别严格的标准。我不打算在这里引用整件事(这是一本好书,无论如何你应该把它捡起来),但这里有一些关键点。
他们给出的一些例子是
无论如何,他们确实认为源文件中的格式应该是一致的。显然,Phobos 在这一点上并不一定坚持这一点,但 Andrei 确实在新闻组中提出了一些通常坚持并正在考虑可能执行其中的一些约定(实际帖子存档在这里)。
然而,虽然 Phobos 是开源的,任何人都可以自由提交补丁,但请记住,它是供公众使用的 API。只有 Phobos 开发人员需要查看代码(至少在文档适当完整的情况下)——当然,他们是唯一将直接处理代码的人——因此不需要公开列出的编码标准,甚至如果他们使用一个。看起来他们确实可以使用更多的一致性,并且他们可能正在为此努力,但是对于第 3 方来说,要做的就是让它更具可读性。没有其他人真正需要知道标准实际上是什么(尽管如果您按照标准查看了足够多的代码,您至少可以或多或少地弄清楚标准所说的内容)。
至于大体上的 D,有一些约定被认为是好的做法(例如,通常使用auto
而不是指定类型,除非您实际上必须指定类型),但就像使用 C++ 一样,您可以使用任何编码风格进行编码想要,并且 D 开发者还不够独裁,无法尝试在整个 D 社区中强制执行某种风格。
事情已经发生了很大的变化,我认为我应该重新回答这个问题。您可以在此处查看当前的 D 风格指南,它现在是最新的。它有一些关于格式的规则(例如,没有制表符,每级缩进是 4 个空格),但几乎所有规则都是关于命名约定的(例如,类型名称应该使用 PascalCase,而变量和函数应该使用 camelCase )。因此,重点是 API 应该是什么样子,而不是代码应该如何格式化。正如我在之前的回答中详述的那样,Phobos 开发人员绝不会尝试为整个 D 强制采用官方格式样式。事实上,有很多 D 程序员甚至不遵循官方风格指南中的命名约定。
It's possible that more restrictive formatting guidelines will be put into place on Phobos itself in the future (it has been discussed but never done) in order to make it clearer to submitters what style they should follow and avoid arguments over code formatting (that's become more of an issue since we moved to github and the number of submitters has increased considerably), but at this point, it primarily just comes down to making sure that the code within a module is formatted consistently. But again, even if more restrictive formatting rules were mandated for Phobos, that would be specific to Phobos and not be for the D community as a whole. And there are far too many different opinions on how code should be formatted for a community wide formatting standard to ever work.