帕雷托法则明确指出，20％的因导致80％的果。又称为80-20法则，它适用于几乎每一个需要人作为劳动主体的相关领域。
在软件开发领域，这个法则可以概括为，大多数的问题都是由少数不良编码习惯造成的。改变这些习惯，你会更有效率。
下面讲讲最要不得的10条编码习惯：
让我特别讶异的是，为什么大家明知这个习惯百害而无一利，竟然还是任其在代码中肆虐横行，以致于经常出现拼写错误的变量名和函数名。更加悲剧的是，错误的拼写常常隐蔽得很好，很难发现。
至于解决方法，可以在一个良好的集成开发环境（IDE）上写代码，或者干脆用程序员专用的文本编辑器，这些都可以显著减少拼写错误。还可以选择特定的变量名和函数名，一方面容易拼写，另一方面即便写错了也能轻易发现。尽量避免使用很容易拼错的单词，例如“receive”，很容易拼写成“recieve”。
缩进和格式化，能让我们的代码一目了然、易于理解，有什么错误也能一览无余。而且也方便别人理解和维护。
如果你使用的是不会自动格式化代码的IDE，那么可以考虑使用代码美化软件，如Uncrustify，这个软件允许用户自定义格式要求，然后它会一丝不苟地执行。
一个函数对应一个指令的习惯相当好，因为简短所以易于理解和维护。长函数实现的可能路径太多，所以测试起来就特别麻烦。
第一个规范原则：一个函数最多只能占一显示屏的空间。第二个：如果有10个以上的if语句或者循环语句，那么你就可以考虑重写了。
毫无疑问，IDE和其他一些工具能让你的代码写得又快又好。在一定范围内它们能提供变量和其他很多东西，给出你想要输入内容的多种选择提示。但是这种类型的工具也存在着风险——如果你不能保证自己有火眼金睛，那么很容易误选相似的变量名。从本质上说，这类工具替代了人的一部分思维，但实际上这是你自己的责任。
工具的确是我们的好帮手，例如可以消除拼写错误，以及提高工作效率等，但是如果你自己不仔细的话，同样会有写错代码的问题出现。
很多人倾向于硬编码一个秘密帐户和密码，这样之后就可以自由进入系统。但是这是不对的——没错，这于你而言的确是大大的方便了，但同时这也大大方便了别人去访问你的源代码。
究其原因在于，硬编码的代码比你想象的还要脆弱，这就使得它成为了一个巨大的安全隐患，而且还是一个很不好修复的安全隐患。
敏感数据在互联网上传输时是需要加密的，因为在这个过程中它很有可能被拦截。不要抱怨麻烦，这是最基本的安全要求。
这也意味着以明文形式发送数据是不被认可的，同时也排除了我们使用自己的加密方式和混淆目标的措施。写安全加密系统是很难的——看看wep的情况就知道了——所以我们不妨使用经过验证的标准加密库。
Donald Knuth，一位传奇的程序员，曾经说过，“程序员将太多的时间花在了思考和担忧程序非紧要部分的进度问题上，因为这些举措反而对效率产生了强烈的负面影响，如果还同时要考虑到调试和维护的话，那么影响更甚。”
善于写代码的程序员的确能让代码跑得更快更顺畅，但是后期调试和维护相反则会变难。提供一个好策略：清清楚楚地写好代码之后，再去找真正需要优化的地方以提高性能。
项目的目标是什么？预计规模有多大？会有多少用户，运行速度得有多快？这些问题乍一看上去好像和我们程序员没啥关系——但是，如果不好好思考这些问题，我们怎么能正确选择开发应用程序的框架，以满足这些要求？
Twitter在这方面就有因为低估未来需求而失败的例子，导致其最终不得不放弃Ruby on Rails，并且重写了很多使用Scala和其他技术的代码，这是因为原先用于架构的Ruby代码，根本跟不上Twitter的快速增长的用户群。
几乎所有的软件项目都会落后于计划。有人会说，人多力量大，落后了那我添加人手不就能跟上进度了吗？听上去挺美的，但事实却是，几乎所有的项目在增加“新鲜血液”之后都发生了“凝血反应”——整体效率不升反降。
接上面第9点，有人会说，既然不能添加人手，那我死命赶进度总可以了吧。我奉劝一句，不要抱这种幻想。如果你远远落后于计划时间，那说明本身你对项目的预估时间就是错的。不要盲目地坚持将错就错，还是早点对项目时间做新的估计吧。
英文：10 Bad Coding Practices That Wreck Software Development Projects 作者：codeceo – 小峰
相关文章
