您遵循哪些Delphi编码标准文档?[关闭]

JEDI Delphi项目语言风格指南及JCL附加功能

(CodeGears对象Pascal风格指南的扩展)

https://wiki.delphi-jedi.org/wiki/Project_JEDI_Delphi_Language_Style_Guide

(感谢Jeroen Pluimers和AmigoJack报道旧链接已失效。 如果这个最新链接也失效, here's its Internet Archive link ,作为良好的衡量标准。)

CodeGears对象Pascal风格指南

http://edn.embarcadero.com/article/10280

Econos编码标准文件

(副标题为Delphi 4开发人员指南编码标准文档。)

http://www.econos.de/delphi/cs.html

About.coms Delphi标识符命名约定

http://delphi.about.com/od/standards/l/bldnc.htm (via Wayback Machine)

只要你选择一个并坚持下去,这真的没关系。编码标准就像一种方言,只要团队中的每个人都说同样的方言,你就没事了。

也就是说,为什么不选择与运行时库(VCL)和文档使用相同的标准呢?然后,你们都会说同一种方言,阅读运行时库代码会更容易。还有很多代码示例来说明编码约定。

有一种倾向是过度设计编码标准,以至于它们阻碍了代码的编写。

我同意Jozz的评论。你可以查看所有推荐的标准,选择一个并将其强加给你的程序员,或者你可以让你的团队参与这个过程。

根据我的经验,让团队参与的最佳方式是让团队提出想法和采用的好处。你现有的天赋是你最好的资源。同样,如果你强迫他们走上他们不认同的道路,他们可能会成为你的最终敌人。

所以,看看你现有的编码变体,让团队一起就以下问题进行一些充满活力的讨论:

• 采用编码标准的原因。
• 标准化的基本考虑因素。
• 在团队中表现出围绕这个问题的任何不安全感。
• 找到一个共识点。什么重要,什么不重要。
• 制定一些公司目标,让每个人都觉得他们正在朝着一个共同的目标努力。
• 让团队向自己推销标准化的好处。

最重要的目标必须是建立一个最能为您的团队和公司服务的标准。

由于一些空洞的历史原因,我工作中的编码标准是所有关键字都是大写的,无论是delphi还是sql。谢天谢地,有了帽子锁。

CodeGears匈牙利花生酱,用于命名标识符

http://dn.codegear.com/article/27983