编程原则

         刚看见数据结构与程序设计这本书时就让我产生了恐惧感，因为都是英文版的读起来很费劲，同时也意识到自己英语水平的低下，感觉学起来会很吃劲，有很多生词需要查，还好本书有中文翻译 以下是对第一章的总结。

         Life游戏实际上是一种模拟，并不是游戏者之间的游戏，它在一个无边界的矩形网格上进行，这个巨型网格中的每一个单元可被一个有机体占据，或者不被占据。被占据的单元称为活的，未被占据的单元称为死的。哪一个单元是活的要根据其周围活的邻居单元的数目而一代代地发生变化，规则如下：

（1）给定单元的邻居是与她在垂直，水平或对角方向上相接的8个单元。

（2）如果一个单元是活的，但没有邻居但愿是活的，或者仅有一个邻居单元是活的，则在下一代，此单元就会因孤独而死亡。

（3）如果一个单元是活的，且有4个或4个以上的邻居单元也是活的，则在下一代，此单元就会因拥塞而死忙。

（4）一个活的单元，如果具有2个或3个活的邻居单元，则此单元在下一代都是活的。

（5）如果一个单元是死的，则在下一代，如果他不多不少刚好有3个邻居单元是活的，则此单元则此单元变成活的。所有其他死的单元在下一代仍是死的。

（6）所有出生和死亡都刚好在同一时间发生，因此正在死亡的单元有助于另一个单元的出生，但他不能通过减少拥塞和阻止其他单元的死亡；正在出生的单元也不能保护或杀死上一代中活着的单元。

              程序设计技术规则

1.编写的每个程序，函数和方法要包含准确的前置条件和后置条件。

2.最审慎地选择类，变量和函数的名称，并予以详尽的解释。

指导原则

（1）特别审慎的选择在程序的不同部分中使用的类、函数、常量和所有全局变量的名称。这些名称应该是有意义的，并且应该能够明确的指示这个类、函数、变量等的目的。

（2）对仅是暂时、局部使用的变量，保持其名称简单。数学家通常使用单个字母代表一个变量，因此有时候当我们编写数学程序时，有可能对数学变量使用单个字母的名称。然而，即使是对控制for循环的变量，也经常有可能找到一个比较短的但却较有意义的单词，他能更好的描述此变量的用途。

（3）使用通用的前缀和后缀来关联同一常规类别名称。

（4）避免采用故意误拼和无意义的后缀来获得不同的名称，在下列所有词中

           index  indx  ndex  index  index2  index3

     只有一个（第一个）应被正常使用。当你试图引用这种类型的多个名称时，用它作为一个警告，告诉你自己应该再仔细想想并设计出更能描述其使用意图的名称。

（5）避免选择那些本身意义与问题毫无关系或只有很少关系的漂亮名称。有些语句可能非常有趣，但它们是低劣的程序设计！

（6）互相接近或者其他方面易于混淆的名称。

（7）应小心的使用字母“l”（小写的ell）、但“O”（大写的oh）和“0”（零）。在词或数中，通常可以以根据上下文区分出他们而不会带来问题，但“l”和“0”绝不应被单独用作名称。

 

3.保持文档简练但具有描述作用：

指导原则：

（1）在每个函数的开始处放上序言，包括：

身份证明（程序设计员的名称、日期和版本号）。

所用函数和算法的目的的说明。

函数所做的修改及其使用的数据。

对程序外部更多文档的引用。

（2）当定义每个变量、常量或类时，解释清楚他是什么及如何使用.如果从名称上就能明显看出这些信息则更好。

（3）对程序的每个重要的片段（段落或函数），用一句注释简要说明它的目的或动作。

（4）如果每个重要片段的结束不明显 则加以指示。

（5）避免机械模仿代码功能的注释。

（6）对任何使用了技巧或意义不清楚的语句加以解释，如果能避免使用这样的语句更好。

（7）代码本身应解释程序是怎样工作的。文档应解释他为什么工作及他做什么。

（8）无论何时修改一个程序，确定文档得到了相应的修改。

4.阅读程序时间比编写程序的时间多得多。使阅读更容易。

5.不要只看一点而不看全部。

6.使用类来模拟程序的基本概念。

7.每个函数应该仅仅完成一项任务，但要好好完成。

8.每个类或函数应该隐藏某些的东西。

9.保持连接简单，尽量避免使用全局变量。

10.只要能够避免，切勿引起副作用。

11.如果必须使用全局变量作为输入，则详细的将他们写入文档。

12.将输入和输出作为独立的函数，使得他们易于修改并能定制修改以适应计算系统。

13.测试数据的质量比数量更重要。

程序测试可用与说明bug的存在，而不能说明其存在。

14.一个大型且重要的程序，超过一半的工作是在它已被完全调试、测试并投入使用后，来自与维护阶段。

15.确信你完全理解了问题，如果必须改变其条件，则确切的解释所做的修改。

最惊心的设计用户接口，程序的成功很大程度上是靠它的吸引力和易用性。

除了必要，不要优化代码。

在代码完善和正确之前，不要开始优化代码。

大多数程序将90%的时间 花在10%的指令上，找出这10%,集中提高它的效率。

16.尽你所能保持算法简单。当犹豫不决时，选择简单的方式。

有事延缓问题会简化解决方案。

17.在需求说明准确和完善前不要进行编码。

太快行动容易后悔，匆匆编程，常常调试。

重新开始经常比给一个旧程序打补丁更简单。

总是计划原型并丢弃它，是否计划都必须这样做。