D/Phobos 风格指南
我刚刚开始查看 Phobos 源代码，它散布着几种不同的样式和注释掉的代码。
网页端的风格指南非常小，我只找到了 2006 年的损坏链接和 2004 年的另一个链接……
是否有更新、更全面的指南可用？
PS：最初是在 D.learn 新闻组询问的，但由于我没有得到任何答案，我想我可以在这里尝试一下，尽管这可能是在黑暗中进行的尝试
I've just begun looking at the phobos source, and it's littered with several different styles and commented out code.
The style guide on the web side is very small, and I only found broken links from 2006 and another one from 2004...
Is there a newer, more comprehensive guide available?
PS: Originally asked at the D.learn newsgroup, but as I didn't get any answers, I thought I might try here even though it might be a shot in the dark
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论存在什么指南都已经过时，不应该再存在。我不相信有任何类型的 D 风格指南被认为是有效的，而且我也不认为 Walter Bright、Andrei Alexandrescu 等人希望有这样一个指南。另外，据我记得，C++ 编码标准：101 条规则、指南和最佳实践，赫伯·萨特和安德烈说风格指南是一个坏主意（或者至少是真正具体的指南），但我必须拿出这本书来确定他们所说的到底是什么。所以我相当怀疑 Phobos（Andrei 负责的）是否有任何风格指南；我当然不知道。可能有某种格式化进入 Phobos 的代码的指南（比如让你的代码看起来与模块的其余部分类似），但像 Andrei 或其他 Phobos 开发人员之一这样的人必须回答这个问题。当然，大约有 15 个不同的开发人员在 Phobos 上工作，如果没有强制的样式指南，您必然会在代码中得到几种不同的样式。
所以，我不认为 D 或 Phobos 真的有任何推荐的编码风格。据我了解，D 背后的主要人物并不特别赞成风格指南，而且他们当然也没有推动过一种风格指南。所以，现在还没有，我也不认为将来会有。
编辑：好的，我去查了一下 Herb Sutter 和 Anderi Alexandrescu 在 C++ 编码标准：101 条规则、指南和最佳实践。与其说它们反对编码标准，不如说它们反对强制个人品味或过时实践的特别限制性标准。我不会在这里引用全部内容（这是一本好书，无论如何你都应该拿起它），但这里有一些关键点。
他们给出的一些例子是，
无论如何，他们确实认为源文件中的格式应该保持一致。显然，火卫一目前不一定坚持这一点，但安德烈确实在新闻组上提出了一些通常坚持的惯例，并正在考虑可能执行其中的一些惯例（实际帖子已存档此处）。
然而，虽然 Phobos 是开源的，任何人都可以自由提交补丁，但请记住，它的 API 是供公众使用的。只有 Phobos 开发人员需要查看代码（至少在文档适当完整的情况下） - 当然他们是唯一将直接处理它的人 - 所以不需要公开列出的编码标准，即使他们使用一个标准。看起来他们确实可以使用更多的一致性，并且他们可能正在努力做到这一点，但对于第三方来说，要做的就是使其更具可读性。没有其他人真正需要知道标准实际上是什么（尽管如果您查看了遵循标准的足够代码，您至少可以或多或少地弄清楚标准所说的内容）。
对于 D 来说，有一些被认为是良好实践的约定（例如通常使用 auto 而不是指定类型，除非您实际上必须指定类型） ，但就像 C++ 一样，您可以使用任何您想要的编码风格进行编码，并且 D 开发人员还没有足够独裁，无法尝试在整个 D 社区中强制执行一种风格。
Whatever guide exists is out of date and shouldn't exist anymore. I don't believe that there is any sort of D style guide which is considered valid, and I don't think that Walter Bright, Andrei Alexandrescu, etc. want there to be one. Also, as I recall, in C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, Herb Sutter and Andrei said that style guides were a bad idea (or at least that really specific ones were), but I'd have to pull out the book to be sure of exactly what they said. So I rather doubt that Phobos (which Andrei is in charge of) would have any kind of style guide; I'm certainly not aware of any. There may be some sort of guidelines for formatting code that goes into Phobos (like making your code look similar to the rest of the module or somesuch), but someone like Andrei or one of the other Phobos developers would have to answer that. Certainly, with about 15 different developers working on Phobos, you're bound to get several different styles in the code if there is no enforced style guide.
So, I don't believe that there really is any kind of recommended coding style for either D or Phobos. As I understand it, the main folks behind D aren't particularly in favor of style guides, and they certainly haven't pushed one. So, there isn't really one right now, and I don't expect there to be one in the future.
EDIT: Okay, I went and looked up exactly what Herb Sutter and Anderi Alexandrescu said in C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. It's not exactly that they're against coding standards so much as they're against particularly restrictive ones which enforce personal tastes or obsolete practices. I'm not going to quote the whole thing here (it's a good book, and you should probably pick it up anyway), but here are some key points.
Some examples that they gave were that
Regardless, they do think that formatting should be consistent within a source file. Obviously Phobos doesn't necessarily stick to that at this point, but Andrei did just bring up on the newsgroup some of the conventions that have typically held to and was looking at possibly enforcing some of them (the actual post is archived here).
However, while Phobos is open source and anyone is free to submit patches, remember that it's the API that's meant for public consumption. Only the Phobos developers need to look at the code (at least if the docs are appropriately complete) - certainly they're the only ones who are going to be working on it directly - so there's no need for a publicly listed coding standard, even if they use one. It does look like they could use more consistency and that they may be working on that, but all that's going to do for 3rd parties is make it more readable. No one else really needs to know what the standard actually is (though if you looked at enough code following a standard, you could figure out at least more or less what the standard said).
As for D at large, there are certain conventions which are considered good practice (such as generally using
autoinstead of specifying a type, unless you actually have to specify the type), but just as with C++, you can code with whatever coding style you want, and the D devs aren't dictatorial enough to try enforce a style on the whole D community.事情已经发生了很大的变化，我认为我应该重新回答这个问题。您可以在此处查看当前的 D 样式指南，它现在是最新的。它有一些关于格式的规则（例如，没有制表符，每级缩进为 4 个空格），但几乎所有规则都与命名约定有关（例如，类型名称应该使用 PascalCase，而变量和函数应该使用 CamelCase） ）。因此，重点是 API 应该是什么样子，而不是代码应该如何格式化。正如我在之前的回答中详细介绍的那样，Phobos 开发人员永远不会尝试为整个 D 强制采用官方格式化样式。事实上，有很多 D 程序员甚至不遵循官方风格指南中的命名约定。
将来可能会对 Phobos 本身实施更严格的格式指南（已经讨论过但从未实施过），以便提交者更清楚他们应该遵循什么风格，并避免对代码格式的争论（这已经变得更加重要）自从我们迁移到 github 以来，提交者的数量已大大增加），但目前，它主要归结为确保模块内的代码格式一致。但同样，即使对 Phobos 强制要求更严格的格式规则，这也将是特定于 Phobos 的，而不是针对整个 D 社区的。对于如何格式化代码才能使社区范围内的格式化标准发挥作用，存在太多不同的意见。
Things have changed enough that I think that I should re-answer this question. You can see the current D style guide here, and it's now up-to-date. It has a few rules about formatting (e.g. no tabs and each level of indentation is 4 spaces), but almost all of the rules are about naming conventions (e.g. type names are supposed to use PascalCase, whereas variables and functions are supposed to use camelCase). So, the focus is on what the API should look like and not how the code should be formatted. And as I detailed in my previous answer, it will never be the case that the Phobos devs try and mandate an official formatting style for D as a whole. As it is, there are plenty of D programmers who don't even follow the naming conventions in the official style guide.
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.