我们公司正在考虑制定更好的编码标准,以提高我们代码的可读性、可审查性和可维护性。我们看到了CodeGear的“Object Pascal Style Guide”,但它已经有一段时间没有更新了,我想许多人可能进行了一些本地改进或添加。我找到了一些发布的变体和其他文档,如下所示。
注意:我不想发动一场格式战。我只想知道您遵循的标准及其原因。
谢谢。
更新:嗯,“JCL Delphi Language Style Guide”似乎是最受欢迎的!谢谢!
项目JEDI Delphi语言风格指南与JCL附加内容
(CodeGear的“Object Pascal Style Guide”的扩展)
https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide
(感谢Jeroen Pluimers和AmigoJack报告旧链接已经失效。如果最新链接也失效了,这是其网站存档链接,以备不时之需。)
CodeGear的“Object Pascal风格指南”
这是一篇关于Object Pascal编程规范的指南,提供了一系列最佳实践,以帮助开发人员编写更加高效、清晰和易于维护的代码。如果您正在使用Object Pascal进行IT技术开发,那么这篇文章将对您非常有用。Econos - 编码标准文档
(副标题为“Delphi 4 开发人员指南编码标准文档”)
http://www.econos.de/delphi/cs.html
只要你选择一个并坚持使用,那么它真的无关紧要。编码标准就像方言一样,只要团队中的每个人都说同一种方言,那就没问题。
话虽如此,为什么不选择与您的运行时库(VCL)和文档使用相同的标准呢?然后,您所有人都将说同一种方言,并且在阅读运行时库代码时会更容易。而且有大量的代码示例来说明编码约定。
在编写代码时,有一种倾向是过度设计编码标准,以至于它们妨碍了编写代码。
我同意Jozz的评论。你可以查看所有推荐的标准,选择一个并强制执行它,或者你可以让你的团队参与到这个过程中。
根据我的经验,让团队提出想法和采用标准的好处是激发团队积极性的最佳方式。你现有的人才是你最好的资源。同样,如果你强迫他们走不认同的道路,他们也可能成为你的终极敌人。
因此,请查看您现有的编码变体,并让团队进行一些充满活力的讨论:
最重要的目标必须是建立一个最适合您的团队和公司的“标准”。
由于某些无聊的历史原因,我们公司的编码标准是在 Delphi 和 SQL 中将所有关键字都大写。感谢上帝有大写锁定键。