避免这些常见的编码习惯将使我们的工作更轻松，我们的软件更安全，更容易扩展。帕累托原则明确指出，20%的原因会导致80%的结果。也被称为80-20法则，它适用于几乎所有需要以人为劳动主体的相关领域。在软件开发领域，这个规律可以概括地说，大部分问题都是由少数不良的编码习惯造成的。改变这些习惯，你会更有效率。先说说最糟糕的10个编码习惯：1.拼写错误令我吃惊的是，为什么人们明知这种习惯有害无益，却仍然任其在代码中横行，以至于变量和函数时常出现拼写错误名字。更可悲的是，拼写错误往往隐藏得很好，很难被发现。作为变通方法，在良好的集成开发环境(IDE)中编写代码，或简单地使用程序员专用的文本编辑器，可以显着减少拼写错误。您还可以选择特定的变量名称和函数名称，一方面易于拼写，另一方面即使您犯了错误也易于发现。尽量避免容易拼错的词，比如“receive”，很容易拼成“recieve”。2、对没有按照规定格式写的代码进行缩进和格式化，可以让我们的代码清晰易懂，有什么错误我们一眼就能看出。其他人也很容易理解和维护。如果您使用的IDE不会自动格式化您的代码，请考虑使用代码美化软件，例如Uncrustify，它允许用户自定义格式要求，然后严格执行。3.按模块化写代码不是一个好习惯。一个函数对应一个指令。因为它很短，所以很容易理解和维护。长函数实现的可能路径太多，测试起来特别麻烦。第一条规范原则：一个功能最多只能占据一个显示屏幕。第二种：如果if语句或者循环语句超过10条，那么可以考虑重写。4、过度依赖IDE毫无疑问，IDE等工具可以让你的代码写得更快更好。他们可以提供一定范围内的变量等很多东西，给你要输入的东西多种选择。但是这种类型的工具存在风险——如果您不能睁大眼睛，很容易错误地选择相似的变量名。从本质上说，这些工具取代了人类思维的一部分，但实际上这是你自己的责任。工具确实是我们的好帮手，比如消除错别字，提高工作效率，但是一不小心，也会出现写错代码的问题。5.使用硬编码的密码很多人倾向于硬编码一个秘密的帐号和密码，以便以后可以自由进入系统。但这是错误的——是的，这确实给你带来了极大的方便，但同时也极大地方便了别人访问你的源代码。这样做的原因是硬编码代码比你想象的更脆弱，这使得它存在巨大的安全风险，而且很难修复。6、没有采取良好的加密措施保护数据敏感数据在互联网上传输时需要加密，因为在这个过程中很可能被拦截。不要抱怨麻烦，这是最基本的安全要求。这也意味着以明文形式发送数据是不可接受的，并且也阻止我们使用我们自己的加密和混淆措施。编写安全的加密系统很难——看看wep——所以我们不妨使用一个经过验证的标准加密库。7.过早地优化代码传奇程序员DonaldKnuth曾说过，“程序员花太多时间思考和担心程序非本质部分的进度，因为这些行为对效率有负面影响。它具有很强的负面影响，如果还要考虑调试和维护，那么影响会更大。”擅长写代码的程序员确实可以让代码运行的更快更流畅，但是后期的调试和维护会变得更加困难。。提供一个好的策略：把代码写清楚之后，再去真正需要优化的地方去8.不提前思考项目的目标是什么？预期规模是多少？会有多少用户，运行速度有多快？乍一看，这些问题似乎与我们程序员——但是，如果我们不考虑这些问题，我们如何正确选择开发应用程序的框架来满足这些需求呢？Twitter有一个在这方面失败的例子，它低估了未来的需求，导致它最终不得不放弃RubyonRails，使用Scala等技术重写大量代码。跟不上Twitter快速增长的用户群。9.认为人多了会加快进度几乎所有的软件项目都会失败会落后于计划。有人会说，人多力量大，我落后了，我加人不就赶不上进度了吗？听上去很美，但事实是，几乎所有的项目在加入“新鲜血液”后都会出现“凝血反应”——整体效率不增反降。10.如果你知道自己的错误，就不要改正。如果您犯了错误，请转到上面的第9点。有人会说，既然不能加人手，那我尽量赶进度就好了。我的建议是，不要有这样的幻想。如果你远远落后于进度，那么你对项目时间的估计是错误的。与其一味地坚持犯错，不如早点对项目时间进行新的预估。翻译链接：http://www.codeceo.com/article/10-bad-coding-break-project.html英文原文：10BadCodingPracticesThatWreckSoftwareDevelopmentProjects翻译作者：晓峰
