一篇好的代码，就如同一篇好的文章，结构合理，重点清晰，通俗易懂。积累了足够多的编码经验，在完成功能之余，自然会追求自己的代码更“好看”一些，接下来就谈谈我对于“好代码”的理解。
遵循规范
没有规矩，不成方圆，遵循编码规范，是最基本的素养。在公司，一般都会有公司规定的若干规范，在编码时，时刻提醒要遵循这些规范，命名规则、缩进规则、换行规则……团队不分大小，哪怕是个人独立项目，风格统一的代码，是确保代码可读性的前提。
如果实在不知道应该遵循怎样的编码规范，不妨找找看语言官方是否有推荐的规范说明，比如C#，微软官方就提供了一套编码规范。或者，我们可以找某个大公司的编码规范，这些规范一般都是经过了实际项目实践过的，可以放心使用。
养成了习惯之后，代码就如同学生时代写作文那样，无论内容好坏，首先“卷面分”是能拿到的。
有意义的命名
为你的类、方法、变量选择有意义的命名，相信我，这非常重要，好的代码应该是“自解释”的，不仅可以提高代码可读性，也提高了可维护性。假如，仅仅半年后再读自己的代码时，看着满篇莫名其妙的名称，连代码要实现什么业务逻辑都想不起来了，能做的就只有怀疑人生了吧。
* 类的命名，应该体现出“是什么”。比如一个提供文件读写功能的类，叫做 FileAccessor 就比 FileHelper 好一些，当然或许分解成 FileWriter 和 FileReader 更适合，但这要视需求而定。
* 方法的命名，应该体现出“做什么”，描述这个方法实际做了什么处理。比如我们有一个根据名称排序的方法，那么叫做 SortByName 就比简单的 Sort 拥有更好的可读性。
* 变量的命名，如同类，也应该体现“是什么”。比如一个保存文件完整路径的变量，叫做 a 的话，简直是反人类，叫做 f 好歹能让我猜想这是个有关 file 的变量，如果叫做 filePath 我给90分，如果是 fileFullPath 我就给满分。
足够短的方法体
一旦一个方法写得太长，势必堆积了大量的逻辑，一旦涉及到很多嵌套或者逻辑分支，不说将来的维护难度，就是当下，很容易就把自己也绕懵了吧。
所以一旦法相一个方法体过长，就应该考虑是否需要把一个完整的逻辑段提取成一个独立私有方法了，这样以来，不仅缩短了单个方法的长度，让逻辑更加清晰，也可以有效的降低风险，因为简短代码的逻辑复杂度势必降低，开发人员更容易把握住。
至于“过长”是多长呢？根据个人经验，25行就值得引起注意了，50行基本就是可忍受的上限了，除非及特殊情况，否则尽量不要超过这个上限。曾经维护过单个方法2000多行的人瑟瑟发抖，往事不堪回首。
无歧义的行为
具有隐含行为的方法，危害极大。一个方法，尽量只做一个事情，不要做额外的事，否则很容易带来意想不到的风险。
举个例子，我自己写过的一个方法。基本数据结构类似堆栈，每次从集合中取出一个对象之后，将这个对象移出集合。但是我的方法名称是 GetXXX，结果就是发现每次取一个对象之后，集合莫名其妙（其实业务就是这样没错，但是我不记得这回事儿了）地就会变短，导致后续的处理一塌糊涂。对策有两种，一是把对象移出集合的逻辑拿到 GetXXX 的调用处来做，这样移除动作就是显示可见的了；或者把方法名改成 PopXXX 或者 GetAndRemoveXXX （丑了点，但好歹看得懂），这样以来，至少我们的行为与名称是一致的，消除了歧义。
以上只是简单列举了一些最基本的准则，希望对同样希望写出“好代码”的同行有帮助，感谢阅读。