您遵循哪些 Delphi 编码标准文档?
我们公司正在考虑制定一些更好的编码标准,以提高我们代码的可读性、可审查性和可维护性。我们遇到了 CodeGear 的“Object Pascal 样式指南”,但很长一段时间都没有接触过它,我想很多人已经对本地进行了一些改进或添加。我遇到了一些已发布的变体和其他文档,我将在下面列出。
注意:我不想开始一场风格大战。我只是想知道你遵循什么标准,以及为什么。
谢谢。
更新: 嗯,“JCL Delphi 语言风格指南”似乎是明显的赢家!谢谢!
您遵循哪些 Delphi 编码标准文档?
我们公司正在考虑制定一些更好的编码标准,以提高我们代码的可读性、可审查性和可维护性。我们遇到了 CodeGear 的“Object Pascal 样式指南”,但很长一段时间都没有接触过它,我想很多人已经对本地进行了一些改进或添加。我遇到了一些已发布的变体和其他文档,我将在下面列出。
注意:我不想开始一场风格大战。我只是想知道你遵循什么标准,以及为什么。
谢谢。
项目 JEDI Delphi 语言风格指南与 JCL 添加
(CodeGear 的“Object Pascal Style Guide”的扩展)
https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide
(感谢 Jeroen Pluimers 和 AmigoJack 报告旧链接已经失效。如果这个最新链接也失效了,这里是它的 Internet 存档链接,很好。)
只要你选择一个并坚持下去,这真的没关系。编码标准就像方言,只要团队中的每个人都说同一种方言,就可以了。
也就是说,为什么不选择与您的运行时库 (VCL) 和文档使用相同的标准呢?然后你们都会说同一种方言,阅读运行时库代码会更容易。并且有大量的代码示例来说明编码约定。
可能存在过度设计编码标准的趋势,以至于它们妨碍了编写代码。
我同意乔兹的评论。您可以查看所有推荐的标准,选择一个并将其强加给您的编码人员,或者您可以让您的团队参与该过程。
根据我的经验,让团队参与的最佳方式是让团队提出想法和采用的好处。你现有的才能是你最好的资源。同样,如果你强迫他们走他们不接受的道路,他们可能会成为你的终极敌人。
因此,请查看您现有的编码变体,并让团队一起就以下方面进行一些充满活力的讨论:
最重要的目标必须是建立一个最适合您的团队和公司的“标准”。
由于一些愚蠢的历史原因,我工作的编码标准是在 delphi 和 sql 中将所有关键字都设为大写。感谢上帝的大写锁定。
CodeGear 的“匈牙利花生酱”,用于命名标识符