每个程序猿桌上必备的经典

《代码大全》里很多观点对我的想法起了一个印证的作用，其中讲到用goto来编写错误处理一段完全重现了我之前开发时得出来的同样的经验。关于具体的编程的一些内容和现在的编程语言已经有一定差距了，不用怎么管，但此外的，讲项目的，讲心态的相当重要。一本牛X的书却起了一个烂的中文名字，这点很可惜。这本书应当买 一本放在手头，在开发的过程中遇到相关问题了，就翻下说不定能获得一些灵感。下面是引起我共鸣的一些内容的摘录。

* 设计是一个险恶的过程：需要先解决一遍才能认清问题。7.5.4很有趣，值得多看几次。

* 关于变量名：理想的变量名长度为9到15个字符，函数名更长一点。在书中多次提到变量名，好的变量名能对代码的作用起到解释的作用，使得注释成为多余。

* 注释并不是必须的，只是在需要的时候才注释。更多的时候应当依靠代码本身来说明代码的作用。代码的易读性很重要，一方面是是使用好的变量名，另一方面是使用函数包装具体的单一功能使得程序结构清晰。

* 子程序长度是100~150行时，错误率最低。

* 结构化设计是把程序分解为子程序，强调的是操作。面向对象是把程序分解为对象，强调的是数据。面向对象的4类要素是：问题域要素、用户接口要素、任务管理要素、数据管理要素。这也是面向对象要考虑的4类对象。我认为类应当是以数据为核心的一系列操作。若操作不是对同样的数据做操作，就只能算作在一个名字空间下，或静态方法。

* 输入垃圾，输出不能是垃圾。

* 面向领域编程：定义类型的命名要用问题域中的类型，而不是编程语言自身的类型。程序的结构应当能体现问题域，整个思路也应该是按照问题域来编写，而不是仍停留在函数库的接口层面上。

* 单元测试、功能测试、部分测试、联合测试。

* 该用全局变量时就用。

* 使用逻辑变量。

* goto用来释放资源的例子和我自己开发时想到的方法是完全一致的。只不过我自己后来用了更好的方法。

* 不要用递归计算阶乘。

* 项目越大，开发的效率越低。

* how to win friends and influnce people

* 软件质量保证最好的方法是控制软件的开发过程。

* 制造错误并不是罪过，不能从中学习才是罪过。

* 书上同样讲到在解决问题时不要钻牛角尖，不要过于坚持，在解决问题时设定一个时限，发现自己仍解决不也时，考虑一下别的思路，或是给别人讲述一下。当感到焦虑时，就要走一走，让心情平复下来。


还有一些残余的问题：

* 代码检查、普查、阅读有什么区别？评审比测试能发现更多错误。