关于<<提高代码质量系列>>
　　这是我新开的一个系列，旨在记录我对整个编码规范，代码风格，语法习惯，架构设计的一些思考，感悟和总结.
　　前言
　　不知道大家会不会觉得我的标题很噱头，不是一般应该提倡写注释的么?首先我得解释下，我这句话有两个意思!
　　1，绝非提倡不写注释，而是不要写不必要的注释.
　　2，命名规范的作用大于注释
　　好吧，这么一说，其实还是有点噱头的感觉的，因为我这篇文其实重心更放在强调命名规范和设计规范上面，良好的规范，让你的代码有自释性，省去了注释的步骤.
　　还要强调下的是:这个观点绝非我自己主观臆断，凭空瞎想出来的. 而是实实在在由项目开发里面总结出来的.
　　为什么我有这个想法呢?请继续看我的蛋疼经历.
　　正文
　　先上段奇葩代码
/// <summary>
///     根据产品ID获取产品列表
/// </summary>
/// <param name="columnID">关键字</param>
public DataTable GetColumnInfoByColumnID(int columnID)
{
return DALColumn.GetColumnInfoByColumnID(columnID);
}
/// <summary>
///     根据产品名称获取产品列表
/// </summary>
/// <param name="columnID">关键字</param>
public DataTable GetColumnInfoByColumnID(string columnName)
{
return DALColumn.GetColumnInfoByColumnID(columnName);
}
　　这是我现在维护的一个老项目了，经手的人比较多，代码写的比较垃圾，我们先不吐槽这种纯粹是脱裤子放屁的所谓三层和明明返回的是dataTable又扯什么info，说这两个函数，tm功能应该是不一样的吧，为啥名字一模一样?这是在闹哪样?
　　其实，造成这种情况的原因，我们都知道，是某类程序员的ctrl c+v大法，这两个函数底层逻辑比较相似，懒得重构，直接copy了改改多快!copycopy吧，好歹名字改一下啊!也许这位前辈会说，我不是写了注释了吗，看到注释，不知道这个函数是干嘛的了?但问题是，其他调用的人，首先看到的，肯定是函数名啊，GetColumnInfoByColumnID，多直观 通过id来查找呗.虽然这里有两个比较违和的地方，一是参数默认名字是columnName，二是参数类型不是int而是string，但反正这项目的代码不规范，如果调用的人也够粗心，那么，一个隐晦的bug，这么产生了.
　　如果改下名字，叫 GetTableByColumnName，这种错误发生的概率无疑会减少很多了，
　　Ps:其实现在ide功能这么强大，只要你确定没有反射调用这个函数的地方，完全可以使用全局重命名的方法，一步到位.
　　看到这里读者朋友们可能会说，这是命名不规范嘛，和写不写注释有什么关系呢?
　　我们可以假想一种这样的情况，同样是拷贝代码，拷贝者改了函数名，这个名字语义清晰，表意清楚， 但他却忘记改注释了，结果函数是新的函数签名，函数的注释却是其他一段莫名其妙的注释.
　　或者再假想一种情况.
　　原来的一个函数，名字和注释是对应的，随便举个例子，叫GetTypeByColumnId吧，注释为"通过产品id取得产品类型"
　　一切ok，是吧! 但是现在逻辑变了，比如说Type和产品无关了，需要通过生产批次来确定，于是一个代码维护者，将函数重写了一下功能ok，满足新需求!!同时他比上个人好一点，他记得改函数名，然后他改为了GetTypeBySerialId，这名字也很ok，一切也都看起来很好.但偏偏他漏掉了注释，但代码仍然运行的很ok，毕竟注释可不受.net的元数据的支持，ide也不可能知道你这里犯了这么一个错误是吧!
　　然后，接下来的场景大家很容易可以联想到，
　　如果是细心的调用者:
　　尼玛!函数注释让我传"产品id"，但函数名和参数默认名字又是"SerialId"(流水号)，这尼玛闹哪样?
　　如果是粗心的调用者呢?两种情况呗:
　　1.看了函数名字和默认参数名字 ，没注意到注释，ok，算这个粗心的小伙伴幸运，
　　2.看了注释，然后这小伙伴不认识SerialId这个单词的意思. 然后，一个悲伤的故事这么发生了!!
　　其实我以上举例的一些函数，都是功能比较具体，业务比较单纯，也容易用几个单词描述.对于这些函数，我个人的意见是，完全不需要去写注释，