您遵循哪些 Delphi 编码标准文档？
您遵循哪些 Delphi 编码标准文档？
我们公司正在考虑制定一些更好的编码标准，以提高代码的可读性、可审查性和可维护性。 我们已经看到了 CodeGear 的“Object Pascal 风格指南”，但它已经有一段时间没有被触及了，我想很多人已经做了一些本地改进或添加。 我遇到了一些已发布的变体和其他文档，我将在下面列出。
注意：我不想想要发起一场风格之战。 我只是想知道你遵循什么标准，以及为什么。
谢谢。
UPDATE: Well, the "JCL Delphi Language Style Guide" seems to be the clear winner! Thanks!
What Delphi coding standards document(s) do you follow?
Our company is looking at putting some better coding standards in place, to improve our code’s readability, reviewability, and maintainability. We’ve come across CodeGear’s “Object Pascal Style Guide”, but it hasn’t been touched in quite a while and I imagine a number of people have made some local improvements or additions. I’ve come across some published variations and other documents, which I will list, below.
NB: I do not want to start a style war. I just want to know what standards you follow, and why.
Thanks.
UPDATE: Well, the "JCL Delphi Language Style Guide" seems to be the clear winner! Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
由于一些愚蠢的历史原因，我工作的编码标准是在 delphi 和 sql 中所有关键字都大写。 感谢上帝的大写锁定。
For some inane historical reason, the coding standard at my work is to have all keywords in uppercase, in both delphi and sql. Thank god for caps lock.
CodeGear 的“匈牙利花生酱”，用于命名标识符
http://dn.codegear .com/article/27983
CodeGear’s “Hungarian peanut butter”, for naming identifiers
http://dn.codegear.com/article/27983
添加 JCL 的 Project JEDI Delphi 语言风格指南
（CodeGear 的“Object Pascal 风格指南”的扩展）
https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide
（感谢 Jeroen Pluimers 和 AmigoJack 报告旧链接已失效。
如果这个最新链接也失效了， 这是它的互联网档案链接，作为一个很好的衡量标准。）
Project JEDI Delphi Language Style Guide With JCL Additions
(An extension of CodeGear’s “Object Pascal Style Guide”)
https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide
(Thanks to Jeroen Pluimers and AmigoJack for reporting that the old links had died.
And in case this latest link also dies, here's its Internet Archive link, for good measure.)
CodeGear 的“Object Pascal 风格指南”
http://edn.embarcadero.com/文章/10280
CodeGear’s “Object Pascal Style Guide”
http://edn.embarcadero.com/article/10280
Econos – 编码标准文档
（副标题为“Delphi 4 开发人员指南编码标准文档”。）
http://www.econos.de/delphi/cs.html
Econos – Coding Standard Document
(Subtitled “Delphi 4 Developer's Guide Coding Standards Document”.)
http://www.econos.de/delphi/cs.html
About.com 的“Delphi 标识符命名约定”
http://delphi.about.com/od/standards/l/bldnc.htm（通过 Wayback Machine）
About.com’s “Delphi Identifier Naming Conventions”
http://delphi.about.com/od/standards/l/bldnc.htm (via Wayback Machine)
只要你选择一个并坚持下去，其实并不重要。 编码标准就像一种方言，只要团队中的每个人都说相同的方言，就可以了。
也就是说，为什么不选择与您的运行时库 (VCL) 和文档使用相同的标准呢？ 然后你们都会说相同的方言，并且您将可以更轻松地阅读运行时库代码。 并且有大量代码示例来说明编码约定。
It really doesn't matter as long as you pick one and stick to it. A coding standard is like a dialect, and as long as everyone on the team speaks the same dialect, you're fine.
That said, why not pick the same standard as your runtime library (VCL) and documentation use? Then you will all be speaking the same dialect and you will have an easier time reading the runtime library code. And there are plenty of code examples to illustrate coding conventions.
可能存在过度设计编码标准的倾向，以至于妨碍了编写代码。
我同意乔兹的评论。 您可以查看所有推荐的标准，选择一个并将其强加给您的编码人员，或者您可以让您的团队参与该过程。
根据我的经验，让团队参与的最佳方法是让团队提出想法和采用的好处。 您现有的人才是您最好的资源。 同样，如果你强迫他们走上他们不接受的道路，他们可能会成为你的最终敌人。
因此，请查看现有的编码变体，并让团队聚集在一起进行一些充满活力的讨论：
最重要的目标必须是建立一个最适合您的团队和公司的“标准”。
There can be a tendency to over-engineer coding standards to the point where they get in the way of writing code.
I agree with Jozz’s comment. You can look at all the recommended standards, pick one and force it upon your coders or you can get your team involved in the process.
In my experience, the best way to get a team engaged is to have the team come up with the idea and the benefits of adoption. Your existing talent is your best resource. Likewise, they can be your ultimate enemy if you force them down a path they don’t buy into.
So, take a look at your existing coding variants and get the team together for some vibrant discussions on:
The most important objective must be to establish a ‘standard’ that best serves your team and your company.