大牛的代码是这样写的

什么样的代码才是好代码

**遵循规范
有意义的命名
足够短的方法体
无歧义的行为**
一篇好的代码，就如同一篇好的文章，结构合理，重点清晰，通俗易懂。积累了足够多的编码经验，在完成功能之余，天然会追求本身的代码更“好看”一些，接下来就谈谈我对于“好代码”的理解。

遵循规范

没有规矩，不成方圆，遵循编码规范，是最基本的素养。在公司，通常都会有公司规定的若干规范，在编码时，时刻提醒要遵循这些规范，命名规则、缩进规则、换行规则……团队不分大小，哪怕是我的独立项目，风格统一的代码，是确保代码可读性的前提。

若是实在不知道应该遵循怎样的编码规范，不妨找找看语言官方是否有推荐的规范说明，好比C#，微软官方就提供了一套编码规范。或者，咱们能够找某个大公司的编码规范，这些规范通常都是通过了实际项目实践过的，能够放心使用。

养成了习惯以后，代码就如同窗生时代写做文那样，不管内容好坏，首先“卷面分”是能拿到的。

有意义的命名

为你的类、方法、变量选择有意义的命名，相信我，这很是重要，好的代码应该是“自解释”的，不只能够提升代码可读性，也提升了可维护性。假如，仅仅半年后再读本身的代码时，看着满篇莫名其妙的名称，连代码要实现什么业务逻辑都想不起来了，能作的就只有怀疑人生了吧。

• 类的命名，应该体现出“是什么”。好比一个提供文件读写功能的类，叫作 FileAccessor 就比 FileHelper 好一些，固然或许分解成 FileWriter 和 FileReader 更适合，但这要视需求而定。
• 方法的命名，应该体现出“作什么”，描述这个方法实际作了什么处理。好比咱们有一个根据名称排序的方法，那么叫作 SortByName 就比简单的 Sort 拥有更好的可读性。
• 变量的命名，如同类，也应该体现“是什么”。好比一个保存文件完整路径的变量，叫作 a 的话，简直是反人类，叫作 f 好歹能让我猜测这是个有关 file 的变量，若是叫作 filePath 我给90分，若是是 fileFullPath 我就给满分。

足够短的方法体

一旦一个方法写得太长，势必堆积了大量的逻辑，一旦涉及到不少嵌套或者逻辑分支，不说未来的维护难度，就是当下，很容易就把本身也绕懵了吧。

因此一旦法相一个方法体过长，就应该考虑是否须要把一个完整的逻辑段提取成一个独立私有方法了，这样以来，不只缩短了单个方法的长度，让逻辑更加清晰，也能够有效的下降风险，由于简短代码的逻辑复杂度势必下降，开发人员更容易把握住。

至于“过长”是多长呢？根据我的经验，25行就值得引发注意了，50行基本就是可忍受的上限了，除非及特殊状况，不然尽可能不要超过这个上限。曾经维护过单个方法2000多行的人瑟瑟发抖，往事不堪回首。

无歧义的行为

具备隐含行为的方法，危害极大。一个方法，尽可能只作一个事情，不要作额外的事，不然很容易带来意想不到的风险。

举个例子，我本身写过的一个方法。基本数据结构相似堆栈，每次从集合中取出一个对象以后，将这个对象移出集合。可是个人方法名称是 GetXXX，结果就是发现每次取一个对象以后，集合莫名其妙（其实业务就是这样没错，可是我不记得这回事儿了）地就会变短，致使后续的处理一塌糊涂。对策有两种，一是把对象移出集合的逻辑拿到 GetXXX 的调用处来作，这样移除动做就是显示可见的了；或者把方法名改为 PopXXX 或者 GetAndRemoveXXX （丑了点，但好歹看得懂），这样以来，至少咱们的行为与名称是一致的，消除了歧义。

以上只是简单列举了一些最基本的准则，但愿对一样但愿写出“好代码”的同行有帮助，感谢阅读。