关于代码的可读性浅谈

关于可读性话题的探讨可谓是历久弥新，从古至今，人们一直在探寻着如何能够把自身的知识、经验能够更好的传播下去，越简单易懂，传播速度也快，这也是一种书面表达能力的体现。

本文将主要探讨一下代码的可读性。

为什么研究可读性？

《重构》一书中曾说过，唯有优秀的程序员才能够写出人类能理解的代码。软件的规模越来越大，一个系统通常需要几代程序员来开发维护。然而这些程序员们往往都素未谋面，只能“神交”于代码的字里行间。可见，代码的可读性的重要性，也是一个优秀程序员的标志。

在程序开发的大流中，相信每个人都曾吐槽过他人代码的难以理解，设计之差，然而一味吐槽他人而忽略自身的问题也将走入另一个误区，也就是忽视自身理解力的提高。因此，在我们努力提升自身代码可读性的同时，同样也要提升自身的理解力，多读他人代码，吸取他人经验教训，才能成长的更快！

写得出好代码，也看的懂烂代码（如果过于烂则另当别论），才是高手！

（一）统一的命名规范。在市面上的大多数项目组中，都是有统一的命名规范的，只是规范略有不同而已。统一的规范可以让代码整齐划一像一个人所写的一样，大家读自己的代码当然效率更高，也更容易理解他人的想法。好的规范一定程度上也可以避免新手程序员犯错。关于命名规范的介绍：

<1>变量的命名。变量用来指定数据，所以最好的结构应该是[形容词+名词]，常用的变量命名规范有匈牙利命名法、骆驼命名法、帕斯卡命名法、网上资料很多，可参考https://baike.baidu.com/item/%E5%8F%98%E9%87%8F%E5%91%BD%E5%90%8D%E8%A7%84%E5%88%99/4084105?fr=aladdin；

<2>函数的命名。函数常常指行为，所以最好用[动词+形容词+名词+状态]，命名同变量命名；

<3>类的命名。通常接口前加个I,枚举前加个E，结构体有S开头，等方式，帮助大家更快的识别类型，提高效率；

<4>命名一定要为有意义的命名。有意义的命名就像注释一样，帮助他人更高效的理解程序想表达的思想；

<5>给数字赋予含义。避免在程序中直接出现数字，用有意义的变量名代替，能极大降低阅读成本，否则，代码中突然出现，15,37,等数字，你能知道是什么鬼不；

<6>为他人编码。关于命名的描述，更多的是让其他读者更容易理解代码的含义，开发过程中，多站在他人的角度思考下问题，多思考自己读他人代码时遇到的坑，这样编写出的代码可读性才会更高，协作的效率才能更高。

（二）关于函数的设计

<1>函数体的大小最好在100行之内,这样在编辑过程中通常可以用一屏显示完整个函数，更容易全局的了解函数。反之，函数过大，可能夹杂了过多的逻辑，不符合低耦合的思想，他人在阅读的时候也必须反复滚动视图才能了解整个函数的功能，效率大大降低；

<2>将条件判断放在开头，逻辑放在最后。开发过程中，为了程序的健壮性，往往需要加入许多数据正确性验证，来提高代码的健壮性。将这部分代码放至开头，代码会更聚合，优雅，同时他人阅读时也可以统一略过，直奔逻辑，提高效率；

<3>减少嵌套。多层类似for的循环，往往是编程过程中的又一大坑，随着嵌套的增加，可读性曾指数型下降，更容易把自己绕晕，产生错误。把子循环封装成函数来解决它。同时在循环中，常会遇到一些情况，就会break，或continue,这部分挪到循环的开头，理由类似<2>条。

<4>可读性与耦合性。耦合性越低，内聚性越高的模块可读性自然会更好，因为逻辑设计集中，读者心无旁骛，专注于单一功能。如何降低耦合性。https://segmentfault.com/a/1190000022076171

优雅的代码，常常给人以美的感受，在帮助他人阅读的同时，也是自身逻辑清晰的体现。大家的可读性都高了，团队的协作效率自然也会提高。细节决定成败，愿你注意开发中的每个细节，积少成多，成就大我！

持续总结完善中，强烈欢迎大家给出有效建议，共同改进~~~