《CODE COMPLETE 2(代码大全2)》警句

阅读《代码大全2》，记录了一些经典标语，直抵内心，颇有感触。望与大家共勉，有些路走过了，才知道路不好走，但希望后来者能够避免，不重蹈覆辙。这些努力就是没有白费，希望您能够打印一份，放在案头，百无聊赖之时或遇到困难，望能一读，给您一些小的启发，想必也没有浪费您的时间一读。

1 调试代码的难度是首次编写这些代码的两倍。
2 消除软件缺陷实际上是最昂贵且最耗时的一种软件工作。
3 测试永远不可能彻底证明程序中没有错误。
4 首先为人写程序，其次才是为机器。
5 这段代码暗藏玄机。（应该需要重写或者重构）
6 试图没有错误是最大的错误。
7 阅读代码每小时能够检测出的缺陷要比测试高出80%左右。
8 一步到位的方法明显比两步走的方法更划算。
9 犯罪不是罪过，从中什么都学不到才是罪过。（犯罪其实已经是罪过了）。
10 我的代码不好，所以我得让它们不好懂。
11 不是高手时不假装是高手。（知之为知之不知为不知，是知也）。
12 世界上没有免费的午餐，即使有，味道也一定不会好到哪里去。
13 如果你工作10年，你会得到10年经验还是1年经验的10次重复。
14 如果在寻找缺陷的时候遇到了麻烦，很可能是因为你的代码写的不好。
15 匆忙动手解决问题是你所能做的最低效的事情之一。
16 不要受到所谓捷径的诱惑。
17 好的布局凸显程序的逻辑结构。
18 不要重复自己，复制粘贴即设计之谬。
19 不要为拙劣的代码编写文档—应当重写代码。
20 他们往往喜欢进行琐碎和无理性的修改，而且他们通常不愿意推翻以前不正确的修改。
21 理解程序本身，而不仅仅是问题。
22 你会看到你所希望看到的。
23 程序员们对于很小的修改常常不以为然。
24 大规模的重构孕育着灾难。
25 开发阶段的重构是提升程序质量的最佳时机，因为你可以立刻让刚刚产生的改变梦想变成现实。请珍惜这些开发阶段的天赐良机。
26 把一个结构化程序的脚塞进一只面向对象的鞋子里（怎么描述得这么准确）。
27 找不到错误的最常见的原因仅仅是因为忽视。
28 深入一门语言去编程，不浮于表面。
29 傻子都会为其失误辩护，而多数傻瓜也确实这么做。
30 你无法提升自己的聪明程度，但性格在一定程度上能够改进。事实证明，个人性格对于造就出程序员高手更具有决定性意义。

1 "编码 (coding)"它有一种把已经存在的设计机械地翻译成计算机语言的意味。
2 重要的研发成果常常产自类比。
3 隐喻的作用更像启示，而不是算法。
4 品味一段“深奥的程序”就像面对的是一本出色的小说那样。
5 如果你计划抛弃一个，那么你将会抛弃两个。
6 增量式开发。
7 精心计划，并非意味着事无巨细的计划或者过度的计划。
8 瞄两次，切一次（三思而后行）。
9 让你的经验来引导你吧。
10 软件开发不仅仅是写代码。
11 人生苦短，当有大量更好的选择摆在你面前的时候，在一个荒蛮的软件企业中工作是不明智的。
12 程序员是软件食物链的最后一环，架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。
13 在一开始把事情做好是最合算的，进行非必要的改动的代价是高昂的。
14 发现错误的时间要尽可能地接近引入该错误的时间。
15 充分详尽地描述需求，是项目成功的关键，它甚至很可能比有效的构建技术更重要。
16 你思考的能力取决于你是否知道能够表达该思想的词汇。
17 “深入一种语言去编程”的程序员首先决定他要表达的思想是什么，然后决定如何使用特定语言提供的工具类表达这些思想。
18 不要仅在“一种语言上编程”。

19 险恶的问题就是那种只有通过解决或部分解决才能被明确的问题。
20 没有任何工具是用之四海皆灵的。
21 好的设计源于对一小批关键设计概念的理解。
22 本质的问题 偶然的问题
23 当没人知道对一处代码的改动会对其他代码带来什么影响时，项目也就快停止进展了。
24 软件的首要技术使命便是管理复杂度。
25 保持子程序的短小精悍。
26 从问题的领域着手，最抽象的层次上工作。
27 受着人类固有限制影响的程序员的底线，就是要写出既让自己容易理解，也能让别人容易看懂，而且很少有错误的程序代码。
28 当我解决问题的时候，我从来不考虑美感，我只想着如何才能解决它。但一旦解决了问题，如果解决方法不够优美的话，我就知道做错了。
29 自明的系统
30 就近原则，即把相关的操作放在一起。
31 先别问系统做什么，问问它想模仿什么。
32 以复杂度的观点看，抽象的主要好处就在于它使你能忽略无关的细节。
33 信息隐藏：封装和模块化。隐藏复杂度，隐藏变化源。
34 好的类接口就像是冰山的尖儿一样，让类的大部分内容都不会暴露出来。
35 我该隐藏些什么？
36 为了找到某样事物，你需要查找的地方越少，那么改起它来就会越容易，越安全。
37 当你开发程序任一部分的代码时，都能安全地忽视程序中尽可能多的其余部分。
38 深入挖掘能在问题领域工作，而非在底层实现领域工作的能量吧。
39 阅读代码的次数要比编写代码多得多。
40 如果在两段子程序内编写相似的代码，就意味着代码分解。
41 好的子程序名字能清晰地描述子程序所做的一切。
42 程序中有39%的错误都是属于内部接口错误—也就是子程序间互相通信时所发生的错误。
43 过程的名字中是否用了强烈清晰的“动词+宾语”词组。
44 在防御式驾驶中要建立这样一种思维，那就是你永远不能确定另一位司机将要做什么。你要承担起保护自己的责任，哪怕是其他司机犯的错误。
45 “进攻式编程”在开发阶段让它显现出来，而在产品代码运行时让它能够自我恢复。
46 有时候，最好的防守正是大胆进攻。在开发时，惨痛的失败，能让你在发布产品后不会败得太惨。
47 伪代码编程过程的价值重大，却很少有程序员真正挖掘出该过程的全部能量。
48 测试先行开发 契约式设计
49 一旦你真正开始编码，你和你所写下的代码就会有感情，从而就更难以抛弃不好的设计再重头来过了。
50 不要只停留在你所想到的第一个设计方案上。
51 每一步完成后都要检查你的工作成果，还要鼓励其他人帮你来检查，这样你就会在投入精力最少的时候，用最低成本发现错误。

52 利用构建活动来填补需求和架构中存在的细小问题是一种行之有效的做法。但把蓝图设计精细到已经能完全展现出所有的细节则实在是一种低效做法。
53 就近原则，即把相关的操作放在一起。
54 把变量的引用点集中起来的主要好处是提高程序的可读性。
55 开始时采用最严格的可见性，然后根据需要扩展变量的作用域。
56 方便性 智力可管理性
57 每个变量只用于单一用途。
58 一个好记的名字反映的通常都是问题，而不是解决方案。
59 一个好名字通常表达是what，而不是how.
60 如果你发现自己需要猜测某段代码的含义的时候，就该考虑为变量重新命名。
61 采用任何一项规则都要好于没有规则。
62 规则的存在为你的代码增加了结构，减少了你需要考虑的事情。
63 去掉所有非前置元音（命名变量）。
64 记住，名字对于代码读者的意义要比对作者更重要。
65 不是被动地看见了什么，而是主动发现了什么。
66 你想找到什么，就能找到什么。
67 信息隐藏和模块化。
68 创建超过几百行代码的程序的核心便是管理复杂度。

69 历史包袱：早期设计所遗留下的问题如果没有及时解决，随着时间推移，这些后果会逐渐扩散，以致于我们要付出更大的代价来弥补才行。所以前期实际需要非常谨慎，对于拿不准的地方，宁愿收紧也不能放松。毕竟，向ios那样做加法（不断添加新的功能和API）比Android这样做减法（取消和收回之前公开的机制或者功能）要容易得多。
70 有多少次你花上了两个小时来调试原本只用三十分钟就写出来的代码。
71 /*"/**/ 终结注释
72 理解程序本身，而不仅仅是问题。
73 匆忙动手解决问题是你所能做的最低效的事情。
74 修改代码时一定要有恰当的理由。
75 一次只做一个改动。
76 如果你想不出如何查找类似缺陷，这就意味着你还没有完全理解问题。
77 你会看到你所希望看到的。
78 软件演化的基本准则就是演化应当提升程序的内在质量。
79 复制黏贴即设计之谬。
80 不要为拙劣的代码编写文档—应当重写代码。
81 应该把简单的修改当做复杂修改加以对待。
82 不要把重构当做先写后改的代名词。
83 避免用重构来代替重写。
84 开发阶段的重构是提升程序质量的最佳时机。
85 不成熟优化的主要缺陷在于它缺乏前瞻性。
86 程序员在思考眼前这棵大树到底有多高的时候，还能留意一下整个森林。
87 除非你对需要完成的工作一清二楚，否则绝不要对程序做优化。
88 只有4%的代码造成了50%甚至更多的性能瓶颈。
89 hot spot
90 除非对效果进行测量评估，否则你永远无法确定某次优化带来的影响。
91 你必须期望在你的代码里有错误。尽管这种期望似乎有悖常理，但是你应该期望找到这个错误的人是你，而不是别人。
92 绝大多数错误往往与少数几个具有严重缺陷的子程序有关。
93 缺乏应用领域知识，频繁变动且相互矛盾的需求以及沟通和协调的失效。
94 错误理解设计。
95 自动化测试。
96 改善测试过程的最好办法就是将其规范化，并对其进行评估，然后从评估中获得的经验教训来改善这个过程。
97 明确你犯了哪种类型的错误。
98 从代码阅读的角度分析代码质量。
99 审视自己解决问题的方法。审视自己修正缺陷的方法。
100 在公众面前先指责别人犯了错误，最终却发现错误其实由你而生。
101 把错误的发生稳定下来。
102 在一条死胡同里面走得太久。
103 抛开问题，休息一下。

104 如果你的坑挖得足够深，你总会看到惊人的宝藏。
105 对每次的改进进行量化。
106 改善交流效率的常用方法是采用正式文档。
107 对于小项目（2000行代码或者更少）影响生产率的最大因素莫过于单个程序员的技巧。随着项目规模和团队规模的增大，组织方式对生产率的影响也随之增大。
108 开发软件产品的成本大约是开发软件程序的3倍。
109 随着项目规模的增长，构建活动将只占项目工作的一小部分。
110 在社交场合，活动越正式，你所穿的服装就会越不舒服。
111 安排一些好的代码示例供人参考。
112 强调代码是公有财产。
113 我必须能阅读并理解这个项目的所有代码。
114 重要问题是你是想预测，还是想控制。
115 管理你的管理者意味着你需要告诉他应该这样做而不是应该那样做。你要表现得使你的管理者认为他仍然在管理你。
116 程序员和管理人员都是人，在把他们当人看的时候工作得最好。
117 开发人员花费多至50%的时间用于调试，使定位错误变容易，就能将调试的效率最大化，从而提高项目项目与生产率。
118 增量集成
119 项目及早开始集成。
120 底层的问题冒上来影响顶层系统的情况并不少见，

121 格式化的基本原理指出，好的布局凸显程序的逻辑结构。
122 傻子都会写让计算机理解的代码，而优秀程序员写的是是人能看懂的代码。
123 好的布局是可读性的关键。
124 编程工作量的一小部分是写让机器读的程序，大部分工作是写能让他人看懂的程序。
125 注释应表达代码的意图。代码本身应尽力做好说明。
126 注释代码段时应注重“为何做why”，而不是”怎么做how“。
127 不要注释投机取巧的代码，应重写之。
128 你无法提升自己的聪明程度，但性格在一定程度上能够改进。个人性格对于造就出程序员高手更具有决定性意义。
129 人的智力是有限的，所以应和他人沟通来提高软件质量。
130 对编程和开发过程做试验，是学习编程的有效途径之一。
131 犯错不是罪过，从中学不到什么才是罪过。
132 任何日后出色的程序员前几年就做得很好。
133 不是高手时，不假装是高手。
134 乐于承认错误。
135 透彻理解自己的程序，而不要只是编译看看能否运行。
136 提供实际的状况报告。
137 提供现实的进度方案，在上司面前坚持自己的意见。
138 力图理解编译器的警告，而非弃之不理。
139 真正优秀的程序员知道怎样同别人融洽地工作和娱乐。
140 编程首先是人与人交流，其次才是与计算机交流。
141 我走出校园时，自以为是世上最好的程序员。
142 精致的程序作品也要求许多约束。
143 一劳永逸的懒。
144 有效编程找那个最重要的工作是思考，而人思考时通常不会看上去很忙。
145 根据环境的不同，坚持可能是财富，也可能是负担。
146 如果你工作10年，你会得到10年经验还是1年经验的10次重复。
147 深入一门语言去编程不浮于表面。
148 我想对严肃的程序员说的话就是：要花工作时间的一部分来检讨和提炼自己的方法。即使程序员总是奋力赶进度，或者满足最后期限的要求，对方法的抽象是更明智的长远投资。
149 专业的程序员总是写可读性好的代码。
150 警惕程序出现难以理解的迹象。
151 找不到错误的最常见原因仅仅是因为忽视。
152 应该在编程时使问题难以遁形。
153 “宗教信仰”在软件开发中有着多种表现形式。非要坚持某种设计方法，笃信特定的布局或注释风格，极力避免全局数据。不管哪种情况。都是不合适的。不要盲目跟风。而应使用一种混合的方法。可用激动人心最新方法做做试验，但仍扎根于传统的可靠的方法。
154 “试图没有错误”是最大的错误。
155 架构的本质是管理复杂性，抽象，分层，分治和演化思维是架构师政府复杂性的四种根本性武器。
156 备份，备份，备份，备份，备份，备份，备份，备份，备份，备份，备份，备份…