《代码大全》读后感（一） 代码首先是写给人看的

读《代码大全》与读别的书不一样的就是，总能找到共鸣。书中所讲到的很多问题都是工作中实际会遇到的，很多经验都是从实际工作中总结出来的。很多东西都是以往所看的其他类技术书籍不会提到或者不会重点提到的，但却是自己工作中有深刻体会的。

“代码是写给人看的”便是我感受最深的一条。

关于代码可读性的争论一直存在，各个论坛里社区上总会有关于是否需要加注释的争论，甚至CSDN上还会有用拼音命名是否合适的争论。但只有当自己真正去维护那些不可读或者很难读的代码的时候才会有最深刻的体会。

在读书的时候，老师虽然总是教我们写完作文后读一下来改善自己的作文，但很少有人真正这么做，原因之一是觉得自己的文章不够好或者很烂，羞于回味；原因之二便是，写完了作文就是完成了自己的任务，读自己的文章似乎并不是学生的任务之一。

在学生时代写代码也是一样，堆砌完代码便是成功了第一步，编译通过便是第二步，等到执行输出了想要的结果，便是大功告成，谁会去读自己的代码？谁又会去读别人的代码呢？

可是等到干了程序员的工作，那便是不一样了。

首先，我们要读已有的代码，才能继续自己的工作；有多少人没有抱怨过他人的代码晦涩难懂呢？或者抱怨文档不够呢？

其次，我们很有可能在一段时间后要读自己的代码，如果连自己都不明白自己写的是什么，是不是很尴尬呢？

所以，其实，大家都希望自己能够轻松的读懂代码，指望别人的代码好懂好读，推己及人，自己的代码如果在写的时候就考虑到可读性，岂不是功德无量？

在同一个工程里，我见过好的代码和差的代码共存，自己维护过这样的代码就知道代码风格糟糕的时候是个什么感觉。糟糕的代码，一个类就有15000多行，其中一个函数1500多行，里面嵌套了多层的if-else和多个循环，根本理不清其中的代码逻辑；函数命名看似规范，但和函数实际完成的功能毫不沾边；好不容易有个注释，却发现这个注释是过时的甚至和代码逻辑相悖。好的代码，一个文件里只有一个类，类名和文件名一致，光看类名就知道这个类是做什么的，只看其中开放出来的接口就知道如何使用这个类，该传什么参数；每一个子函数和成员变量都有清晰的名字，不需要看代码也不需要注释就知道函数的功能，函数短小精悍。调试差的代码的时候简直就是噩梦，如果不重写或者重构，改一个bug能够引入5个新的bug，改个提示信息都得弄懂所有逻辑后才敢动手；易读的代码，虽然也可能出问题，但是定位起来相当简单，改起来相当放心，不会担心说改了后会影响别的功能。

确实，好代码就如好文章，要写出来很难；但至少我们可以逐步改进，至少我们可以让自己或别人读得不那么难受。

让代码易读很难，不能随便用a,b,c和x,y,z给变量与函数命名，需要仔细遵循命名规则，需要根据是成员变量还是局部变量添加不同的前缀，有的时候需要查询字典或者翻译工具才能给出一个长度合适，表述准确和便于理解的名字。

改善代码的易读性也不难，适当添加空行，利用IDE的缩进功能调整好缩进，代码该放在一行的就放在一行，该分行的就分行，适当添加空格，整个工程的代码采用同一风格，就能让代码看得更舒服些。

让代码易读很难，不能将所有的代码行堆砌在一个函数里，也不能将所有的函数都堆砌在一个类里，不能随随便便的写代码，而需要深思熟虑。

改善代码的易读性也不难，在写代码之前理清逻辑，按照逻辑写代码，给代码分段，那么很容易写出短小精悍内聚高的函数和类。

总而言之，要写出好代码是很难的事情，但是逐步提高总不会太难。重要的是，你喜欢读自己的代码吗？如果自己都不喜欢读，那么让代码变得好看一些，至少要自己能读得懂。好好阅读他人的好代码和差代码，自然而然就会知道可读性的重要性，然后按照<<代码大全>>里面的方法逐步改进吧！

隔一段时间回味一下自己的代码，说不定会发现愚蠢的笔误，不可理喻的命名，糟糕的逻辑，这些都是可以逐步改进，让自己的代码变得更漂亮一些，更漂亮的同时，代码往往也会更健壮，更稳定，更可靠，至少，自己不至于过于讨厌自己的代码，工作也变得愉快了些，不是吗？