6个你在编程中应尽量避免的坏习惯

经过多年的开发经验，我养成了一些好的习惯，同时也发现了一些我会尽力避免的坏习惯。本文就讨论一些我总结的开发过程中的坏习惯。这里讨论都是我的个人观点。本文所谓的坏习惯也许是其他开发者秉持的好习惯。

坏习惯一，依赖代码格式化工具

很多程序员都喜欢用代码格式化工具来美化他们的代码。当我新安装一个IDE或者代码编辑器比如Visual Studio的时候，我通常做的第一件事就是禁止代码格式化工具。我这么做是基于以下几个原因，

• 好的程序员应该有好的习惯。即使你不认为使用代码格式化工具是个坏习惯，你也许会认同随手写出美化的代码是个好习惯。那么既然随手写出的都是美化的代码，代码格式化工具也就不需要了。
• 格式化工具产生的格式不符合我自己的代码风格。我在代码格式化工具流行之前就已经有了自己的代码风格。比如，有些编辑器格式化C++代码时，if和左括号之间有空格，而我的风格是没有空格的。
• 对于功能强大的编辑器，也许可以通过配置来设置格式化工具来满足我的需求，但是，那要浪费我很多时间，而且我换一个编辑器就要重新设置一遍。更为严重的问题是，有些编辑器无法配置成满足我的需求。
• 对于任何一个和我一样资深的开发者，良好的手动排版的习惯就像呼吸一样自然且高效率。
• 使用代码格式化工具之所以是坏习惯，是因为还有一个坏处，就是在团队开发中，要么所有人都必须使用同一个编辑器同一套代码格式化规则，要么就会因为部分人使用代码格式化工具而造成混乱。

坏习惯二，过度依赖集成开发环境（IDE）

好的集成开发环境和代码编辑器无疑会大大提升工作效率。我自己就有一些长期使用并喜爱的IDE，比如Visual Studio， Qt Creator，Visual Studio Code，等等。但如果你只习惯于某种IDE，脱离了IDE你就无法或者很难工作的话，那么就是一种坏的习惯了。过度依赖IDE会有以下问题，

• IDE替你做了太多的事情，导致你不明白很多底层的原理。比如一般IDE都会替你创建和管理项目文件，那么你就不会了解项目和代码库之间是如何引用的，代码文件之间是如何依赖的，甚至你无法明白资源文件是如何打包到可执行文件里的。
• 对于简单任务，IDE经常会降低效率。比如，如果我要写一个一二百行的单文件的C++程序，我用NotePad++写一个代码文件并在命令行用gcc进行编译，会比用Visual Studi创建一个项目文件更有效率。
• IDE并不总是可用的。比如你到了一个新的项目，你发现整个项目都在用Eclipse而不是Visual Studio来开发C++项目。你最好的选择应该是改用你不太熟悉的Eclipse来保证和团队的步伐一致，这样VS对于你来说就是不可用的了。

我们可以尽情享受IDE带来的效率提升，但我们也要培养习惯，在没有IDE的时候，也能高效率地开发。

坏习惯三，过度依赖调试器（Debugger）

相信你和我一样赞叹Visual Studio或者GDB调试器的功能强大和便利，但减少对调试器的依赖会让我们的开发更有效率，

• 我们应该培养编写“无错”代码的习惯，而避免通过调试器来修复bug。编写绝对无错的代码是不可能的，但我们可以培养好的习惯和编码风格来减少出错的几率。比如说，在C++正确使用智能指针会大大减少内存泄漏的几率。如果你还在显式地使用new和delete来管理内存，那么应该开始使用智能指针来管理内存，而不是依赖调试器来解决内存泄漏的问题。

• 相当多的情况下，打印输出语句比调试器更有效率。事实上我现在即使在有调试器的情况下，我也经常用打印语句来进行调试。

• 调试器并不总是可用，或者不总是方便使用，那么不用调试器来解决问题就显得更为重要。

坏习惯四，对代码进行过多的注释

数不清的公司、团队、所谓的导师和资深开发者，以及所谓的代码规范，都在孜孜不倦地教诲和要求程序员要在代码里写注释和文档。但当我看到代码里有过多注释时，我恰恰认为它是潜在的问题，而不是应该提倡的规范，

• 好的代码应该是自解释的。如果你需要写注释来说明一个函数是干什么用的，那么你应该选择更适合的函数名和参数名，而不是写注释。再次强调，代码是给人读的，不是给机器读的。
• 过多注释会大幅降低代码的可读性。你可以看看很多开源代码库的接口文件，你需要在大片的文档注释中寻找代码。
• 绝大部分时间里，注释都会比代码过时。这样的注释，除了降低代码可读性以外没有其它用处。

请注意，我不是反对在代码里注释，我只是反对用注释来取代提升代码可读性的工作。注释应该出现在以下几个地方，

• 对复杂的算法进行说明
• 对复制粘贴的代码进行出处说明
• 对过于技巧（或者叫hack）的代码进行说明
• 对临时代码进行说明

坏习惯五，不一致的代码和编程风格

这一点也许是最没有争议的一点。在一个项目中，以及一个团队中，无论已有的编程风格是好还是坏，我们都应该保持一致的代码风格。如果项目使用的是MFC风格的m_做为成员变量前缀，那么你也应该保持这种风格，即使你认为这个风格是很过时的。

坏习惯六，“过度努力工作”

你第一眼就发现了标题上的引号。努力工作无疑是好事，尤其是努力创造独一无二有创造性的新事物。但当你发现你在乐此不疲地做着重复的事情，那就有问题了，因为计算机从第一天被发明出来开始就是为了解决重复劳动的。

• 当你重复地拷贝粘贴并修改相同逻辑的代码时，是时候把代码抽象成模块了。
• 当你重复地解决相同类型的bug时，是时候review一下你的设计问题了。
• 当你重复做一个乏味的事情时，是时候掌握一门诸如Python或者Perl的脚本语言来自动完成这些任务了。

结论

看完我列举的所有坏习惯，也许你对某些观点表示认同，某些甚至全部观点表示不认同。没关系，这些本来就是比较主观的观点。