1. 软件质量,不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点无乱是敏捷开发流派还是传统开发流派，都不得不承认。
2. 有人也许会以为，关于代码的书有点儿落后于时代—代码不再是问题；我们应当关注模型和需求。确实，有人说过我们正在临近代码的终结点。
很快，代码就会自动产生出来，不再需要人工编写。程序员完全没有用了。 扯淡！我们永远抛不叼代码(至少在100年以内) 因为代码呈现了需求的细节。
在某些层面，这些细节无法被忽略或者抽象，必须明确之，将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。
记住，代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言。我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而，我们永远无法抛弃必要的精准性—所以代码永存。
3. 糟糕的代码 ，我们都曾经瞟一眼自己亲手造成的混乱代码，决定弃之不顾，走向新一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的程序总比什么都没有强。我们都曾经说过有朝一日后头再清理。当然，在那些日子里我们都不会再回头—稍后等于用不。
4.态度，是否遇到过本来只需要修改一行代码，结果却涉及到了上百个模块的情况。
怎么会发生种事情？ 为什么好的代码会这么快就变质城糟糕的代码？理由很多。我们抱怨需求变化背离了初期设计。我们哀叹进度太紧张，没法干好活。我们把问题归咎于那些愚蠢的经理，苛刻的用户，逗比产品等等，不过这只是为糟糕的代码找理由罢了。说句不中听的，其实是程序员的自作自受，我们整洁我们的代码因为—职业态度
5. 代码整洁规则:
能通过所以测试
没有重复代码
体现系统中的全部设计理论
包括尽量少的实体，比如类，方法，函数等
6.代码是随着事件流失而腐坏的。我们应当积极地阻止腐坏的发生。
如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。清理并不一定要花多少功夫，也许只是改好一个变量名
，拆分一个有一点过长的函数，消除一点点重复代码，清理一个嵌套if语句。
7.函数应该短小,意味着在每个函数中只该有一个return语句，循环中不能有break或continue语句,而且永永远远不能有任何goto语句
8.注释 什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块，什么也不会比陈旧，提供错误信息的注释更有破坏性。
实际上，注释最多也是一种必须的恶。弱编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释—也许根本不需要。
因为注释会撒谎。也不是说总是如此或有意如此，但出现得实在太频繁。注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误，原因很简单。程序员不能坚持维护注释。
9.代码格式,线明确一下，代码格式很重要。代码格式不可忽略，必须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。