代码恶心度判定法则

经常在与群里面的朋友探讨时，常言及某代码极度恶心，或是大家戏谑的贴出自己写的一段代码，展示其恶心程度，今天心血来潮，不禁产生了兴趣，集思广义，与群里们的朋友们简单探讨了一下，大家一致达成了一些共识，有时代码的恶心是无法避免的，但是养成良好的习惯，其实可以大大减少后期重构的时间花费（更何况大部分项目未必有时间重构）：

恶心度判定法则一：混乱的变量命名
无论英文也罢，拼音也罢，中文也罢，命名需要一个统一的标准，这样看起来才舒畅，经常在多人开发的项目中看到变量名的不统一，比如某处写一个变量叫xxx，另一个地方写作yyy，亦或写作x_xxx，诸如此类．
解决：统一变量命名，在对变量命名时团队最好有一个统一的标准

恶心度判定法则二：重复的代码
这是一个很可怕的事情，当在代码中不同的地方有相同功能的代码块出现时，就意味着一旦需要修改这个与这个代码块相关的算法或是结构，就必须得在同时维护几个不同的地方，因为人的记忆力有限的，信息的传递也是有限的，一旦因为某种原因忘记了其中一块，调试起来是一件非常费力的事．
场景：比如访问wmi获取cpu的序列号时，但现在忽然觉得光一个序列号不够用了，应该再加上mac地址，此时的工作本来只需要把这段代码分离，换成一个函数返回一个对象即可解决，但现在有好几处都是这样写的代码块，而不是统一成一个函数来进行调用的，结果就是一改就要连续改很多地方，如果有一个地方忘记了，其中会带来很大的麻烦．
所以在针对重复的代码时，一定要仔细考虑三种情况：
    第一种，返回直接的值变量，完全确定可直接使用，并在此时能够完全确定其日后绝不会有任何扩展或是变化（尽管不可预料，但可尽力做到），极端情况下可以直接返回字段，不过这种情况实际上相对是少见的．
    第二种，有可能发生变化，但这里不太确定的，不过可以完全确认该数据返回的类型，比如一个价格，通常情况下多是decimal或是其它什么，不过返回价格的算法仍然是有可能会发生变化，比如可能会以后要求保留多少位小数进行四舍五入，这种一般就应该设计为函数或是一个属性．
第三种，返回的数据的字段有可能增加或减少，此时哪怕目前只是要求一个字段，也应该采用定义一个类然后返回一个对象的方式来处理，

恶心度判定法则三：需要进行多余转换的变量或函数
为什么说是多余的，实际上这个类似第一种与第二种情况的杂交产物，比如有人已经定义了一个List<A>，并返回，而此处没有达成共识，这里的函数入口是IList<A>，在泛型的情况下，这种情况已经很小了，但仍然会有一个问题是，函数的入口定义成IList时，会让函数内的写码者少享受很多功能．
场景：定义一个 private List<Student> GetStudents()，而另一处的处理是private void Save(IList<Student>)，这里就产生了一个问题，在Save中处理的是IList而不是List，相当于会少了很多享受，对相关类进行分析可以发现，在使用IList与List分别不大，如果已经使用的List，要替换成其它类，在一般中，更多的是List与Dictionary或是Collection上的转换，这个转换后修改的代价是几乎一样的．除非这里实在是有必要，否则一昧替换成接口来处理是一种不明智的行为．