作者：    来源：    点击：    日期：2007-6-5 0:33:13   

目录

• 介绍
  • 标准化的重要性
  • 解释
  • 认同观点
  • 项目的四个阶段
• 命名规则
  • 合适的命名
  • 缩写词不要全部使用大写字母
  • 类命名
  • 类库命名
  • 方法命名
  • 类属性命名
  • 方法中参数命名
  • 变量命名
  • 引用变量和函数返回引用
  • 全局变量
  • 定义命名 / 全局常量
  • 静态变量
  • 函数命名
  • php文件扩展名
• 文档规则
  • 评价注释
  • Comments Should Tell a Story
  • Document Decisions
  • 使用标头说明
  • Make Gotchas Explicit
  • Interface and Implementation Documentation
  • 目录文档
• 复杂性管理规则
  • Layering
  • Open/Closed Principle
  • Design by Contract
• 类规则
  • Different Accessor Styles
  • 别在对象架构期做实际的工作
  • Thin vs. Fat Class Interfaces
  • 短方法
• 进程规则
  • Use a Design Notation and Process
  • Using Use Cases
  • Code Reviews
  • Create a Source Code Control System Early and Not Often
  • Create a Bug Tracking System Early and Not Often
  • RCS关键词、更改记录和历史记录规则
  • Honor Responsibilities
• 格式化
  • 大括号 {} 规则
  • 缩进/制表符/空格 规则
  • 小括号、关键词和函数 规则
  • If Then Else 格式
  • switch 格式
  • continue,break 和 ? 的使用
  • 每行一个语句
  • 声明块的定位
• 流行神话
  • Promise of OO
• 杂项
  • 不要不可思议的数字
  • 错误返回检测规则
  • 不要采用缺省值测试非零值
  • 布尔逻辑类型
  • 通常避免嵌入式的赋值
  • 重用您和其他人的艰苦工作
  • 使用if (0)来注释外部代码块
  • 其他杂项

---

介绍

标准化的重要性

标准化问题在某些方面上让每个人头痛，让人人都觉得大家处于同样的境地。这有助于让这些建
议在许多的项目中不断演进，许多公司花费了许多星期逐子字逐句的进行争论。标准化不是特殊
的个人风格，它对本地改良是完全开放的。

优点

当一个项目尝试着遵守公用的标准时，会有以下好处：

• 程序员可以了解任何代码，弄清程序的状况
• 新人可以很快的适应环境
• 防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯
• 防止新接触php的人一次次的犯同样的错误
• 在一致的环境下，人们可以减少犯错的机会
• 程序员们有了一致的敌人 :-)

缺点

现在轮到坏处了:

• 因为标准由一些不懂得php的人所制定，所以标准通常看上去很傻
• 因为标准跟我做的不一样，所以标准通常看上去很傻
• 标准降低了创造力
• 标准在长期互相合作的人群中是没有必要的
• 标准强迫太多的格式
• 总之人们忽视标准

讨论

许多项目的经验能得出这样的结论：采用编程标准可以使项目更加顺利地完成。标准是成功的关
键么？当然不。但它们可以帮助我们，而且我们需要我们能得到的所有的帮助！老实说，对一个
细节标准的大部分争论主要是源自自负思想。对一个合理的标准的很少决定能被说为是缺乏技术
性的话，那只是口味的原因罢了。所以，要灵活的控制自负思想，记住，任何项目都取决于团队
合作的努力。

解释

惯例

在本文档中使用“要”字所指的是使用本规范的所有项目需要遵守规定的标准。

使用“应该”一词的作用是指导项目定制项目细节规范。因为项目必须适当的包括 (include），
排除(exclude)或定制（tailor）需求。

使用“可以”一词的作用与“应该”类似，因为它指明了可选的需求。

标准实施

首先应该在开发小组的内部找出所有的最重要的元素，也许标准对你的状况还不够恰当。它可能已经概
括了 重要的问题，也可能还有人对其中的某些问题表示强烈的反对。

无论在什么情况下，只要最后顺利的话，人们将成熟的明白到这个标准是合理的，然后其他的程序员们
也会发现它的合理性，并觉得带着一些保留去遵循这一标准是值得的。

如果没有自愿的合作，可以制定需求：标准一定要经过代码的检验。

如果没有检验的话，这个解决方案仅仅是一个建立在不精确的基础上的一大群可笑的人。

认同观点

1. 这行不通；
2. 也许可行吧，但是它既不实用又无聊；
3. 这是真的，而且我也告诉过你啊；
4. 这个是我先想到的；
5. 本来就应该这样。

如果您带着否定的成见而来看待事物的话，请您保持开放的思想。你仍可以做出它是废话的结论，但是做

首页 上一页 [1] [2]  下一页 尾页