(至少对于 PHP 项目来说——请注意 PHP 是开源的,并且有一个重要的社区;所以,很多事情都是由社区中所做的事情驱动的)
首先,当在项目中使用框架时(即,始终),如果明确定义,我们会尝试坚持其策略(至少 Zend 框架就是这种情况):它确保任何来参与这个项目的人都可以:
- 找到标准的定义
- 在使用相同框架的任何其他项目中重新使用它
- 即使去另一家公司,或为另一位客户工作
- 或来自另一家公司时;-)
考虑到在我工作的公司中,我们只为 PHP 项目使用了 3 到 5 个框架,而且他们的标准中定义的许多规则都是相同的,这不是一个真正的问题。
当然,如果在某种 CMS 内部/周围进行编码,同样适用。
在不使用特定框架时,我们会尝试遵守 PHP 社区广泛接受的一组通用规则:同样,它确保这些规则是众所周知的(即使是我们公司的新手) em>,很容易找到,而且很多人都尝试过并对其进行了改进。
关于 cmets,有一个在 PHP 中很好用的工具:phpDocumentor (与 javadoc 差不多);它定义了一个标准——这是事实上的标准,因为没有其他工具使用得这么多。
关于具体的评论标签:
- 我们总是使用 @param / @return :它们集成在 IDE 中,提供类型提示,非常有用
- 否则,我们不会使用太多:几行来说明该方法在不明显时的作用;如果使用困难的算法,则需要几行代码。
Camel-case 或其他:我们坚持 PHP 社区和框架中的共同点:
this_is_a_function
和
ThisIsAClassName
和
thisIsAMethodName
在 HTML 中:我们尽可能不使用 HTML cmets,因为它们是发送到浏览器的:
- 意味着更大的页面(好吧,不是那么多)
- 表示放弃用户不需要的信息
如果可能,我们使用模板引擎中的 cmets。
在 CSS 中:我们在需要时发表评论;更重要的是使用几个小的 CSS 文件,非常具体(即使在构建过程中使用了合并工具)
但是,也许比这一切更重要:我们尝试使用“干净”的代码,使用只做一个小的“单元”事情的小方法,使用自描述的名称和所有
它没有魔法,但它有助于理解代码......而且,测试它,重用它,......
此外,正如 Nate 所说:这些主要是指导方针——除非客户特别要求......在这种情况下,您必须放置一些自动工具 (例如,在您的构建过程中) 来验证它们后面是字母。