说起代码可读性，对于每一个程序员来说，或多或少的都会遇到一些这方面的坑。比如说：逻辑太复杂，代码写的杂乱无章，注释太少，方法名起的很随意，完全没有业务意义等等，这些都是在维护别人代码中可能遇到的问题。为什么强调代码的可读性，其实也就是为了解决这些坑带来的问题。
你心目中的代码第一优先级要求是什么？
说起我心目中代码的第一优先级的话，那自然是功能逻辑要符合业务需求，但是功能逻辑本身也是系统的本质功能，不能算要求。那么这样的话，我心目中当然是觉得代码的第一优先级应该是可读性。从业良久，接手别人的项目也不少，在日常维护以及版本迭代过程中，最让人头皮发麻的就是当你需要迭代某一个功能时，发现原始功能本身的业务逻辑就很复杂，而你需要理解的代码又没有什么层次，没什么结构，也没什么注释，整个放在一起就是一堆字母的堆砌。这个时候你就会真的意识到代码可读性对于代码维护来说究竟有多重要，可以说好的代码有层次、有结构、有注释、可以一眼看出代码是要干什么，对于维护这样的代码，那简直就是一件享受的事，对吧。而遇到我上面说的一堆字母的堆砌，可以说不管你是大神还是小开发，你都是同样的头大。因此我心目中代码的第一优先级必须是“可读性”。
你在提升代码可读性的一些做法
对于《一文聊聊代码的可读性》文中提到的代码可读性体现的三个方面：语言表达、明确意图、层次结构，我个人是比较认可的。其实代码可读性的实现或者说习惯的建立，本身并没有那么复杂，而是很简单，只需要摒弃一些日常的坏习惯就可以做到的。比如说代码注释，代码层次结构等，都是我日常工作中提升代码可读性的常用的。
语言表达
语言表达其实很容易理解，在日常交流中就是要让别人能轻松明白你想要表达的意思即可，无需多余的点缀。那么体现到代码可读性上的话，就是说你的代码中需要有一定的中文注释，可以明确表达某一段代码需要实现的业务逻辑；同时在你代码中的方法名、类名、变量名，也需要可以一眼看出其中的意思，而不能不遵守命名规范，随心所欲的命名，导致后来的维护者一脸懵，完全不知道自己到底在经历着什么人间折磨。因此，通俗易懂的注释，契合业务的方法命名都是提高代码可读性的必要手段。
明确意图
明确意图也就是说代码的维护者看到的代码业务逻辑以及实现逻辑是和代码的开发者是一致的，这就是明确意图。反过来说的话就是，比如你写了一段业务逻辑代码，是要实现A的业务逻辑；而后来的维护者却通过你的代码注释，代码方法名等的理解却理解为与A相反的或者说与A有岔路的B业务逻辑，那么这个时候就是说你的代码没有明确的意图，不利于后期维护者的迭代开发。这也就要求每一个开发者都可以明白自己心中想要表达的意思，并且可以通过多种外部的方式来帮助后来的维护者可以理解到同等的意思，这就是好的代码可读性。
层次结构
说到层级结构，真的是不同的开发者不同的习惯。最惊奇的就是有的开发者自己写的代码，过两天回头看，其中的业务逻辑自己都看不明白的。层次结构就是说对于你的代码，要有层次，整个业务逻辑从上到下清晰明了，任何人看了之后都能明白你想要表达的意图，这就是好的层次结构。比如说日常开发中，一段业务逻辑完成之后空行区分，不同的业务逻辑之间条理清晰，有注释。不同业务代码之间不要有交叉，尽可能的让代码整洁易读。还要就是代码中不同层次的大括号有一定的空行等，这些都是日常工作中保持代码层次结构的好办法。
以上内容希望对大家在代码开发中提高代码可读性起到一定的帮助作用。
