编程中,那些一直被认为是好习惯的坏习惯

习惯1：认为注释越多越好

为什么：

在编码中，因为担心忘记自己所写代码的意思，我们会在尽可能多的地方添加注释。为此，我们内心可能还会充满自豪，觉得自己的代码可读性强。但是事实却并非如此，因为写入的注释会成为代码的一部分。既然是代码的一部分，那么当代码及上下文发生变更时，就必须同步的去更改注释，这会使工作量增大。然而主要的问题还不是工作量的增大，代码发生变更，注释却没有同步变更才是更大的问题。未变更的注释会严重影响阅读者对代码的理解，从而不敢去改动这块代码。

怎么办：

那么，我们如何在没有注释的情况下使代码具有高可读性呢？我想我们可以先从函数及变量的命名入手。刚开始时，也许我们需要较长的函数及变量命名才能完整的体现其功能。但是随着我们实践次数的增多，我们就能用越来越精简的命名实现函数及变量的功能准确表达。一开始不要担心过长的函数及变量命名会导致代码不美观，相较于代码表面的美观，我们其实更应该关注代码的可读性。

习惯2：函数及变量命名上使用大量的简写

为什么：

在编码中，为了整个文件的代码整齐、美观，我们通常会有强烈的冲动简写单词来缩减函数及变量的命名长度。然而随意使用简写单词来命名，会造成函数及变量的意思难以理解，降低整个工程代码的可读性。想象一下，有人打开你的工程，看到满屏的简写单词函数命名，他肯定是一头雾水的。接着他到网上查询简写单词的意思，发现尽是各种千奇百怪的解释，那是让人多么抓狂的一种场景啊。

怎么办：

为了代码的高可读性，我们需要在函数及变量命名上较完整的表示其功能，只有那些被众所周知的单词我们才能使用他的简写去命名函数及变量。

习惯3：为使代码简单化引入第三方库，反而降低了代码的可读性

为什么：

对于新掌握的技术或者方法，我们总是会很想在项目中使用。一遇到看似符合的场景，我们就会直接使用上去。这大概就是所谓的，手里拿着锤子的人,看啥都像钉子。所以当我们有这样的冲动时，我们不妨先考虑下，对于代码的实现，我们的首要原则是什么。我觉得应该是在满足需求的前提下，尽可能的提高代码的可读性。一旦项目中引入了不常见的第三方库，那么就意味着其可读性的降低，因为总有大部分的人不了解这个东西。

怎么办：

在使用一些不常见的第三库时，我们首先要考虑下是否有更简单的实现方式，在充分考虑的基础上，再去确认是否需要导入第三方库。

习惯4：为了代码的通用性，使用大量的宏

为什么：

在产品开发中，一个产品往往是由多个系列组成的。为了一套代码能用在所有系列产品，通常开发人员会在代码中添加多个宏，以在不同系列产品切换。然而代码总趋向于熵增。随着时间的推移，人员的流动，代码中的宏会越来越多，逻辑越来越复杂。从而使整个代码非常难于维护。想象一下这样的场景，你想修改一个功能，看着满屏的宏定义，你要先确认哪些宏是要打开哪些是不打开的。确认完后去修改代码时，你会看到需要使用的和不需要使用的代码交替混杂在一起，那是多么让人痛苦的场景啊。

怎么办：

在项目工程中，我们要尽量减少功能开关宏的使用。且要为功能开关宏的使用定下统一的原则，比如开关宏只能用于外设功能(例如是否支持人脸识别、指纹识别等)的裁剪。在实现外设功能的文件外，只能在指定某几个地方出现。总之，就是要在框架上做好规划，有了统一的规划和原则，我们就能快速理清宏定义所代表的意思。

习惯5：为了使代码看起来简洁，使用不易读的语法

为什么：

其实这一点，跟使用第三方库有点类似。在代码实现过程中，我们有时候会为了缩减代码行数而使用不易读的语法。例如，如下的三目运算符

对于以上的代码实现，我们在看代码时，脑袋需要多转两下才能搞清它的意思，这对代码的阅读体验来说是比较差的。

怎么办：

对于代码的实现，我们尽量使用常见的语法。为了进一步提高代码的可读性，我们可以将上图的语句表达封装成函数，通过函数的命名直观的知道函数所实现的功能。本来是将上面语句写成更易理解的函数。奈何这个代码不止是使用三目运算的问题。在变量的命名上也完全表达不了其意思，而且一个功能没有做到内聚，分散在整个模块。实在看不懂，只能放弃。

习惯6：对所有内存分配失败进行简单的异常值返回处理，导致设备发生异常时，无法重启

为什么：

在项目开发中，我们总是会习惯性的对所有malloc返回的空指针情况进行异常值返回处理。这样当执行某个功能malloc失败时，该功能就无法正常执行，但是看门狗又能正常喂狗。这时，整个系统就会在异常状态下一直运行，无法恢复。

怎么办：

对于小空间malloc失败的情况，我们应该直接让系统重启。因为小空间malloc失败，就说明系统存在内存泄漏的情况。如果不进行系统的重启，设备就会一直处于功能异常状态，无法恢复。

习惯7：认为需要在一个功能被完整实现后，才能进行代码提交

为什么：

在项目开发中，我们总是有一种习惯。一个功能必须被完整实现后才会去提交代码。但是如果等到功能完整实现后再去提交代码，可能会出现代码提交冲突。更麻烦的是，如果在代码调试时出现死机等问题，没有办法快速的通过代码回退定位到问题。

怎么办：

在功能模块设计时，可以有意识的再去拆分模块。基于更小的功能模块或者函数进行代码的提交，养成小代码提交的习惯。

习惯8：工程中满是注释掉的代码

为什么：

在对代码进行优化或者弃用某块功能代码时，我们总是觉得这部分代码会在后面用到，因而只是将其注释掉。后续接手这部分代码的人，不清楚这部分代码有没有用，因而继续放着。随着接手的人越来越多，代码也开始变得越来越杂乱，越来越影响阅读。

怎么办：

对于被优化或者弃用的功能代码我们需要及时删除，保持代码的整洁，提高代码的可读性。