每一个程序员都该知道的10大编程格言

每一个程序员都该知道的10大编程格言（Kevin Pang）：

• 编程格言1：无风不起浪 (There is no smoke without fire）

• 编程格言2：预防为主，治疗为辅(An ounce of prevention is worth a pound of cure：）

• 编程格言3：不要把鸡蛋都放在一个篮子(Don't put all your eggs in one basket) 

• 编程格言4：种瓜得瓜,种豆得豆（As you sow,so shoul you reap）

• 编程格言5：欲速则不达（Great haste makes great waste）

• 编程格言6：三思然后行( Look before you leap。Think first, Program later)

• 编程格言7：当你仅有的一把工具是锤子，全部的东西看起来都像是钉子（When the only tool you have is a hammer, everything looks like a nail）
  

• 编程格言8：沉默就是赞同 （Silence is construed as approval）

• 编程格言9：双鸟在林不如一鸟在手（A bird in the hand is worth two in the bush）
  

• 编程格言10：能力越大责任越大（With great power comes great responsibility）

1.无风不起浪(There is no smoke without fire)：

设计糟糕的代码一般表现如下 的一些现象：

•  巨大的类或者方法

• 大区块注释的代码

• 重复的逻辑

• 过多 if/else 层次嵌套

2. 预防为主，治疗为辅(An ounce of prevention is worth a pound of cure）磨刀不误砍柴工

    程序员常常错误地认为高效率编码就是快速编码，不少程序员不经思索和设计就直接编写代码。很不幸地是，这种 Leeroy Jenkins鲁莽作法将会编写出槽糕的代码，结果致使须要不断维护和修改代码，甚至有可能这些槽糕的代码将会被替换掉。所以，编码效率不只以编码的时间，并且还有调试代码的时间。

捡了芝麻丢了西瓜。磨刀不误砍柴工。

3. 不要把全部鸡蛋放在一个篮子 （Don't put all your eggs in one basket)不要过分依赖某我的

一个软件项目开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。好比某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。
换言之，若是团队的关键成员忽然流失，项目将会怎么办？业务仍继续仍是中止呢？

所以咱们在项目开发中， 每位开发人员最好能最熟悉软件系统非本身所擅长的部分。

4.种瓜得瓜，种豆得豆 （As you sow, so shall you reap)

《注重实效的程序员》一书中有这样一段话解释“破窗理论”：

不要留着“破窗户”（不良的设计、错误的决策或者糟糕的代码）不修。发现一个就修一个。若是没有足够的时间进行适当的修复，就先把它保留起来。或许你可 以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采起一些措施，防止进一步的恶化。这代表局势尚在掌控之中。

咱们见过整洁良好的系统在出现“破窗”以后立马崩溃。虽然促使软件崩溃的缘由还有其余因素（咱们将在其余地方接触到），但（对“破窗”）置之不理，确定会更快地加速系统崩溃。

简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了习惯的力量。没人想去整理糟糕的代码，一样没人想把完美的代码弄得一团糟。写好你的代码，它才更可能经得住时间的考验。

5 .欲速则不达（Great haste makes great waste)

经理、客户和程序员正日益变得急躁。一切都须要作的事，都须要立刻就作好。正因如此，快速修复问题变得很是急迫。

没时间对一个新功能进行适当的单元测试？好吧，你能够先完成一次测试运行，而后你就能够随时回来继续测试它。

当访问Y属性时，会不会碰到奇怪的对象引用错误？不管怎样，把代码放到try/catch语句块中。咱们要钓到大鱼啦！

是否是似曾相识呢？这是由于咱们在之前已经都作到了。而且在某些状况下、它是无可非议的。毕竟，咱们有最后期限，还得知足客户和经理。但不要过于频繁操 做，不然你会发现你的代码不稳定，有不少热修复、逻辑重复、未测试的方案和错误处理。最后，你要么是把事情草草作完，要么是把事情好好作完。

6. 三思然后行（ Look before you leap)

“敏捷开发”这个词最近被频繁滥用，常常被程序员用来掩饰他们在软件开发过程当中的糟糕规划/设计阶段。咱们是设计者，看到产品朝正当方向有实质进展，咱们理应高兴。但意外的是，UML图和用例分析彷佛并不能知足咱们的愿望。因此，在不知本身作什么的状况下或者不知本身身处何处时，咱们开发人员常常就稀里糊涂地写代码了。

这就比如你要去吃饭，但你根本没有想好去哪里吃。由于你太饿了，因此你火烧眉毛地找个餐馆，定个桌位。而后你上车开车后沿途在想（找地方吃饭）。只是，这样会耗费更多的时间，由于你要过较多的U型弯道，还在餐馆前停车，也许最后因等待时间过长而不吃了。确切地说，你最后应该能找到地方吃饭，但你可能 吃的饭并非你想吃的，而且这样花费的时间，可能比你直接在想去的餐馆订餐所花的时间更长。

7.当你仅有的一把工具是锤子，全部的东西看起来都像是钉子（When the only tool you have is a hammer, everything looks like a nail）

                                              看见了吧？我早就说过动态记录在这个项目中颇有效
程序员有一种倾向，当一谈到他们工具时，其视野就变狭窄了。一旦某种方法在咱们的一个项目上“行得通”，咱们就会在接下来全部的项目上都用到它。学习新东 西仿佛是一种煎熬，有时候甚至会心猿意马。从始至终都在想“若是我用以前的方法作、这个就不会这么麻烦了”。必定要摒弃这种想法，按咱们所知道的去作，即便那不是最完美的解决方法。
坚持本身所知很简单，不过从长远的角度讲，选择一个适合这项工做的工具要容易得多。不然，就会与你的职业生涯格格不入。

8. 沉默就是赞同（Silence is construed as approval）

我什么都没看见！没看见！

"破窗理论"与"变成惯性理论"有着宏观的联系。

编程社区就好像一个现实社区。每一个做品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。若是你不去努力编写优秀、整洁和稳定的代码，那你天天都将和糟糕的代码相伴了。

一样地，若是你看到别人写出了糟糕的代码，你就要跟这我的提出来。注意，这时候机智就应该用上场了。通常状况下，程序员都愿意认可他们在软件开发中仍是有不懂的地方，而且会感谢你的好意。互相帮助对你们都有利，而对问题视而不见，只会使问题一直存在。

9.双鸟在林不如一鸟在手（A bird in the hand is worth two in the bush）

若是能够讨论系统架构和重构，那么就差找个时间把事情作完。为了使正常运做的东西更加简洁而作改动，权衡改动的利弊很重要。固然了，简洁是一个理想目标， 但总会有能够经过重构改进的代码。在编程世界中，为了代码不过期，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也须要找到平衡点。

10.能力越大责任越大（With great power comes great responsibility）

毫无疑问，软件已成为咱们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者航空交通管制系统中的Bug是另一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美圆。其余例子参见《软件Bug引起的十次严重后果》。这些例子便说明了咱们正行使着多大的权利。你今天写的代码，不管你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想一想都使人惧怕。编写正确合格的代码吧！