认识达内从这里开始

我们在前几期的文章中曾经提到过，对于程序员来说，代码可以写的比较慢但是一定要有规范，这样才能在后期的工作中方便查找以及辨认，下面我们就一起来了解一下，好的代码都有哪些特点。

遵循规范

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

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

养成了习惯之后，代码就如同学生时代写作文那样，无论内容好坏，先“卷面分”是能拿到的。

有意义的命名

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

*类的命名，应该体现出“是什么”。比如一个提供文件读写功能的类，叫做FileAccessor就比FileHelper好一些，当然或许分解成FileWriter和FileReader更适合，但这要视需求而定。

*方法的命名，应该体现出“做什么”，描述这个方法实际做了什么处理。比如我们有一个根据名称排序的方法，那么叫做SortByName就比简单的Sort拥有更好的可读性。

*变量的命名，如同类，也应该体现“是什么”。比如一个保存文件完整路径的变量，叫做a的话，简直是反人类，叫做f好歹能让我猜想这是个有关file的变量，如果叫做filePath我给90分，如果是fileFullPath我就给满分。

足够短的方法体

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

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

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

无歧义的行为

具有隐含行为的方法，危害极大。一个方法，尽量只做一个事情，不要做额外的事，否则很容易带来意想不到的风险。

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

作者：高云鹏

节选：博客园

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!