来给你代码加上美颜吧！-技术圈

每个程序员只要不犯错，都能写出机器能看得懂的代码，程序能正常跑起来，自然就意味着机器正常识别了程序。

但是，真正牛逼的程序员是写出能让人看得懂的代码。

不要小看这个，虽说我们写的代码确实是跑给机器的，但是代码是人写的，而通常一个项目的开发，需要多个程序员一同协助开发，这时能写出 human readble 的代码就显得至关重要，因为不仅可以减少后期维护的时间成本，而且还能让后面加入的新同事能更快的上手项目。

要能写出干净、整洁并让人易懂的代码，必然离不开一些规则，只要自觉遵守、合理运用这些规则，代码通常都不会太差。

事实上，每个公司或者开源项目都有各自的编码风格指南文档，这些文档无不例外都罗列了十几个、上百个的条款，基本上都是干干巴巴的示例和说明，不说能不能看完，即使看完了，也都忘了差不多，非常容易被劝退。

这次，我就从中抽离几个重要的条款，以及结合我工作的经验，把写出好的 code style 的几个注意事项跟大家说下。

只要注意代码格式、变量命名和注释三个方面，代码的“颜值”起码提高 80%。

往大的说，能写出“高颜值”的代码的人，也能从这个小事反映出他是一个细心的人，同时也具备责任感，只要把每一件小事做好、做到极致，渐渐的，你的同事和上级就会对你产生信任感。

代码格式

第一眼看代码就是看代码的整体格式，好的代码格式，一眼就能让人感到清爽、舒服，我们本身每天工作就比较繁忙了，还要面对乱糟糟的代码格式，心情肯定差到极点，感觉像是吃了一坨 shi。

文章也是一样，小林我也很注重文章的排版，我的排版也被很多读者夸赞过，不用追求花里胡哨的装饰，只要保持简洁、大方就行，虽说文章是我写的，但是文章是给别人看的，那我肯定要为读者的“眼睛”负责呀。

一个好的代码格式，只需要遵循五个字，那就是「留白的艺术」。

代码和文章，不要为了节约篇幅，把一大坨东西“挤”在一起，这样只会给人家带来压迫感。

多运用空格和换行，用空格分隔开变量与操作符，用空行分割开代码块。

说了那么多口水话，接下来上点实际代码例子。

来，我上一大坨的代码给大家看看：

是不是很密集？看的很难受？压迫感++ 是不？

什么？你说你没感觉，那你被我逮到了，你肯定是经常写这类车祸现场代码的凶手，搞崩团队心态的发动机。

运用好「留白的艺术」，代码就变成下面这样：

是吧，只需简单运用空格和空行，代码就显得很清爽，段落层次分明，读起来不会太累，也更加容易理清代码的逻辑。

所以，敲代码的同时，别忘了用空格和空行“装饰”下你的代码，你的每一处留白，都是在拯救别人的眼睛。

变量命名

不知道你是不是写过变量名为，a、b、c、d... 的代码，如果代码只是你测试用的，那也问题不大，但是我不信在你把代码越写越多后，还记得这些变量的作用。同样，也不要在一个多人维护的项目里，干出这样的事情，你十有八九会被同事孤立。

给变量命名是有讲究的，不是随意的，取的名字应该是让人知道该变量的作用，减少大家根据上下文才猜测的时间。

命名最好以英语的方式描述，而不要汉语拼音，英语词汇不过关也没事，敲代码本身就是一个“开卷考试”的事情，打开浏览器，随意都能在各种翻译网站找到合适的英语词汇。

另外，有一些变量名在程序员之间已经形成了普遍共识，这些都是可以直接使用的，比如：

用于循环的 i/j/k；
用于计数的 count；
表示指针的 p/ptr；
表示缓冲区的 buf/buffer；
表示总和的 sum；
…

对于变量命名的风格，一般应用比较广泛的有三种。

第一种风格叫「匈牙利命名法」，早期是由微软的一个匈牙利人发明的，当时 IDE 并没有那么智能，识别不出变量的类型，代码量一大起来，要确定一个变量的类型是个麻烦的事情，于是就要求使用变量类型的缩写作为变量名的前缀字母，代码例子如下图：

但是这个风格在面临代码重构时，就是一个灾难了，因为如果更换了变量的类型，那么还得把变量名也全部改过来，所以这种风格基本被淘汰了。

不过它里面还有一种做法还是不错的，对于有作用域的变量会加上对应的前缀来标识，给成员变量加 m_ 前缀，比如 m_count，给全局变量加 g_ 前缀，比如 g_total，这样一看到前缀就知道变量的作用域了，很清晰明了。

第二种风格叫「驼峰式命名法」，主张单词首字母大写，从而形成驼峰式的视觉，对于变量的首字母有的要求是小写，有的要求是大写，比如 myName、MyAge。这种风格在 Java 语言非常流行，但在 C/C++ 语言里用的比较少。

第三种风格叫「下划线命名法」，变量名用的都是小写，单词之间用下划线分割开，比如 my_name、my_age，这种风格流行于 C/C++ 语言。

这些风格也不是说只能固定只能用一种，我们可以结合一起使用的，我常用的语言是 C/C++，我对自己一般有以下这几个规则：

变量名、函数名用下划线命名风格，对于有作用域的变量，也会使用前缀字母来标识，比如成员变量用m_、全局变量用 g_、静态变量用 s_；
类的名字用驼峰式命名风格，比如 VideoEncode、FilePath;
宏和常量用全大写，并用下划线分割单词，比如 MY_PATH_LEN；

下面用实际代码作为例子：

关于变量命名还有一个问题是，名字的长度如何才是合理的。

有一个普遍被大家认可的原则是：名字越长，它的作用域应越广。也就是说，局部变量的名字可以短一些，全局变量的名字可以长一些。

注释

留白的艺术用上，变量名规范也用上，让每个人都能一眼看懂的代码，还差点东西，那就是注释。

注释存在的原因就是为了让人快速理解代码的逻辑，一个好的注释，是能让人只看注释就知道代码的意图。

我猜大家注释也写了不少，注释一般是用来阐述目的、用途、工作原理、注意事项等等，注释必须要正确、清晰、言简意赅，而且在修改代码逻辑时，也别忘记了要更正注释，否则就会误导人了。

注释最好写明作者、时间、用途、注意事项这四个信息，比如下面这个例子：

注释用中文好还是英文好呢？

当然是英文比较好，因为英文在 ASCII 或 UTF-8 编码格式里兼容性很好，而中文可能会在导致在一些编码格式里显示乱码，乱码了就自然失去注释的作用了。

注释最好也要统一使用一个标准格式，比如 Java 语言一般是使用 Javadoc 注释标准，遵循该标准后，会有专门的工具可以一键生成 API 文档。

比如下面这个，是比较常用注释文件的一种标准：

再来，如果你发现某个地方的代码有改进或未实现的地方，而暂时没有时间去修改的时候，可以使用 TODO 来标识它，这样代码需要优化的时候，直接搜索这个关键词就可以了，也可以给将来的维护者一个提醒。比如：

注释要写的好，得要有换位思考的思维，想着写怎么样注释能让那些没有参与过该项目开发的人能最快速的理解，以便能加快他们融入该项目的速度。

总结

要写出高颜值的代码，离不开良好的编程习惯，今天主要提了三个重要点：

留白艺术的妙处，多运用空格和空行；
变量名、函数名、类名要起个让人容易理解的名字；
注释要写好，多换位思考，最好也要遵循一些注释标准，便于自动生成 API 文档；