规范3

目录文档 所有的目录下都需要具有README文档，其中包括： 该目录的功能及其包含内容 一个对每一文件的在线说明（带有link），每一个说明通常还应该提取文件标头的一些属性名字。 包括设置、使用说明 指导人民如何连接相关资源： 源文件索引 在线文档 纸文档 设计文档 其他对读者有帮助的东西 考虑一下，当每个原有的工程人员走了，在6个月之内来的一个新人，那个孤独受惊吓的探险者通过整个 工程的源代码目录树，阅读说明文件，源文件的标头说明等等做为地图，他应该有能力穿越整个工程。-------------------------------------------------- ------------------------------ 使用设计符号和流程 程序员需要有一种通用语言来谈论编码、设计、以及一般的软件流程。这对于项目的成功至关重要。任何项目都会聚集具有不同技能、知识和经验的人员。即使项目中的每个人都是天才，你仍然会失败，因为人们会无休止地互相谈论，因为没有共同的语言和流程将项目绑定在一起。你所得到的只是大规模的战斗、精疲力竭，而且进展甚微。如果您派您的团队去参加培训，他们可能不会回来经验丰富的专家，但至少您的团队都会达成共识；一个团队。有许多流行的方法。关键是做一些研究，选择一种方法，对你的员工进行培训，然后使用它。查看本页顶部的各种方法的链接。您可能会发现 CRC（类责任卡）方法对于梳理设计很有用。许多其他人也有。这是一种鼓励团队合作并关注做事的对象而不是具有属性的对象的非正式方法。甚至有一整本书：Nancy M. Wilkinson 的《Using CRC Cards》。 -------------------------------------------------- ------------------------------ 使用用例 用例是涉及多个对象的整个事务的通用描述。用例还可以描述一组对象（例如组织）的行为。因此，用例模型呈现了用例的集合，并且通常用于指定整个应用程序系统以及与系统交互的一个或多个外部参与者的行为。单个用例可能有一个名称（尽管它通常不是一个简单的名称）。它的含义通常被写成对外部参与者以及构成交易的对象之间的事件序列的非正式文本描述。用例可以包含其他用例作为其行为的一部分。需求捕获用例尝试以可理解的形式捕获系统的需求。这个想法是通过运行一组用例，我们可以验证系统是否正在做它应该做的事情。根据需要拥有尽可能多的用例来描述系统需要完成的任务。流程首先要了解您要构建的系统。创建一组用例来描述所有不同受众如何使用系统。为系统创建类和对象模型。运行所有用例以确保您的模型可以处理所有情况。更新您的模型并根据需要创建新的用例。 -------------------------------------------------- ------------------------------ 开放/封闭原则 开放/封闭原则规定类必须是开放和封闭的，其中：意味着一个类具有扩展的能力。关闭意味着类对于除扩展之外的修改是关闭的。这个想法是，一旦一个类通过代码审查、单元测试和其他资格程序被批准使用，您就不想对该类进行太多更改，只需扩展它即可。开/闭原则是为了稳定。通过添加新代码而不是更改已经工作的代码来扩展系统。程序员通常不愿意更改旧代码，因为它有效！这个原则只是为你的恐惧提供了一个听起来学术上的理由:-) 在实践中，开放/封闭原则仅仅意味着充分利用我们的老朋友抽象和多态性。抽象出共同的流程和想法。继承以创建派生类必须遵守的接口。 -------------------------------------------------- ------------------------------ 契约式设计 契约式设计的思想与 LSP 密切相关。合同是对另一方期望的正式声明。在这种情况下，契约是在代码片段之间进行的。一个对象和/或方法声明它执行 X 并且您应该相信它。例如，当您询问一个物体的体积时，您应该得到它的体积。由于体积是事物的可验证属性，因此您可以运行一系列检查来验证体积是否正确，即它是否满足其契约。在像 Eiffel 这样的语言中，契约是通过前置和后置条件语句来执行的，这些语句实际上是该语言的一部分。在其他语言中，需要一点信仰。通过契约设计与基于语言的验证机制相结合是一个非常强大的想法。它使编程更像是组装指定的零件。 -------------------------------------------------- ------------------------------其他事项这一部分包含各种该做的和不该做的。在需要使用分散的分数使时，不要使用浮点数。采用浮分数来循环分数无异于向自己的脚开枪。测试浮点数时总要使用 ，永远不要用 = 或 => 。 不要使用程序自动美化器，得益于好的程序样式的主要的人就是程序员自己，特别是刚开着手代 码、算法设计的程序员，使用程序自动美化器仅仅能根据语法来更正程序，因此当对空白和缩进 的注意有很大需要时，它是不可能做到的。正常的细心注意细节的程序员们能很好的用清晰直观 的样式来完成一个函数或文件（换句话来说，一些直观的样式是意向的规定而不是程序自动美化 器能读懂的智慧）。马虎的程序员应该学习细致的程序员，不要依赖程序自动美化器来增加程序 的可读性。最初的美化器是必须分析源代码的程序，复杂的美化器不值得通过这样获得好处，美 化器最好用于生成总的机器建立（machine-generated）格式代码。 对逻辑表达式第二个 = 不小心的忽略是一个问题，以下显得混乱而且更像是错误： if ($abool= $bbool) { ... } 程序员在这里真的是要赋值么？一般常常是，但通常又不是这样。这样避免引起这样的混乱呢？解 决方案就是不要这样做，利用显式和隐式的判断测试，推荐的方法是在做测试前先做赋值： $abool= $bbool; if ($abool) { ... } -------------------------------------------------------------------------------- 使用if (0)来注释外部代码块 有时需要注释大段的测试代码，最简单的方法就是使用if (0)块： function example() { great looking code if (0) { lots of code } more code } 你不能使用/**/，因为注释内部不能包含注释，而大段的程序中可以包含注释，不是么？ -------------------------------------------------------------------------------- Different Accessor Styles Why Accessors? Access methods provide access to the physical or logical attributes of an object. We disallow direct access to attributes to break dependencies, the reason we do most things. Directly accessing an attribute exposes implementation details about the object. To see why ask yourself: What if the object decided to provide the attribute in a way other than physical containment? What if it had to do a database lookup for the attribute? What if a different object now contained the attribute? If any of the above changed code would break. An object makes a contract with the user to provide access to a particular attribute; it should not promise how it gets those attributes. Accessing a physical attribute makes such a promise. Implementing Accessors There are three major idioms for creating accessors. Get/Set class X { function GetAge() { return $this->mAge; } function SetAge($age) { $mAge= $age; } var $mAge; } One Method Name class X { function Age() { return $mAge; } function Age($age) { $mAge= $age; } var $mAge; } Similar to Get/Set but cleaner. Use this approach when not using the Attributes as Objects approach. Attributes as Objects class X { function Age() { return $mAge; } function rAge() { return &$mAge; } function Name() { return mName; } function rN