有以下几个原因:
　　1.浪费精力去写，
　　2.调用的人需要把一段话读两遍(函数名和注释)
　　3.写了还需要人去维护，(改了代码，得同步去改注释)
　　4.如果强类型的参数传递不匹配，ide或者resharper插件会马上指出你的错误，但如果注释和代码不匹配，则除了通过人力CodeReview，没有其他任何办法去找出这种错误.
　　其中尤其是4，完全是埋在项目中的地雷，除非你踩到了，不然很难排查.
　　当然，如果是反之，逻辑复杂，甚至有调用的前置约束，那肯定该写注释还是得写了.
　　同时，这里还提一个观点，注释比代码更有价值，因为代码毕竟大部分还是在讲怎么做(how do)，而注释是讲做什么(do what)?抽象程度更高，对于比较复杂的代码，如果有注释，调用者一般都会优先去阅读注释，而不是去阅读代码，所以:轻易不写注释，但如果你写了，请一定要对你的注释负责，它比代码更需要你的细心呵护!!
　　好吧，我会说这篇文大的作用，其实是可以让我吐槽发泄一下么?
　　我感觉自己现在是在这种地雷坑里，天天过着提醒吊胆的日子.
　　以上例子皆非我刻意编造，来源于工作中的真实经历，只是稍作修饰，隐去了和业务有关的信息.
　　根据回复的补充:
　　相信很多博友有这样的经历，这个函数好复杂呀!我必须写注释啊，不然一段时间之后，我自己都看不明白了，
　　有些时候是确实很复杂，但也有时候是设计的问题，这时候，写注释其实是一种逃避了.逃避你需要继续深入思考这个函数的业务和功能的设计是否合理.
　　其实我这标题还有第三个意思:
　　在尽可能少写注释的前提下，如果一个函数的注释仍然超过了2处，那么我认为这个函数的设计是有问题的.
　　这个函数是否太大，是否是反模式里面提到的万应灵或屠龙术?
　　所以有时候说的 "因为业务复杂，很难用几个单词去描述，所以很难命名"，是如此.
　　你的业务抽象粒度是否太大?导致一个业务模块承担了过多的业务.
　　你是否把几个流程放在了一个节点上?导致引入了额外的逻辑判断甚至是多余的逻辑分支.
　　如果是这样，你想用几个单词来描述这么复杂的逻辑，当然是不可能了.
　　这点我会在后续的重构系列里面谈谈我自己的理解.
　　补充下自己的理解.
　　我始终认为好的设计，大部分情况下，函数名足以解释它的功能，如果你遇到了两三个单词不能解释函数功能的情况----说明你该分解函数了!
　　比如一个大函数，OutPutMetaData，输入是源数据路径，使用的模板 返回解析之后的元数据
　　流程大概是 采集数据->分析数据->匹配模板->生成MetaData
　　代码是大约1-2k行，如果写在一个函数里面，当然也似可以的，但你想用注释解释清楚，必须在每个流程的关键节点写注释，遇到数据有前后关联关系的，还得思维反复跳来跳去.
　　但如果写成下面这种模式的代码，基本像是阅读英文说明(注释)，一样阅读代码了
public MetaData OutPutMetaData(string sourcePath， MetaTemplate template)
{
var metaDataFactory = new MetaDataFactory();
if (!metaDataFactory.CheckInput(sourcePath))
{
throw new ErrorSourceException();
}
if (!metaDataFactory.TransformSourceData(template))
{
throw new ErrorFormatException();
}
return metaDataFactory.CreateMetaData();
}
　　这样写虽然多了很多的类和方法，还要额外定义一些中间数据的实体类型和自定义异常，但是经过合理的封装和命名之后，整个结构非常清晰，定位错误和修改流程也方便.
　　代码阅读速度基本和描述语句(注释)的阅读速度相当， 这是代码即注释.
　　后总结:
　　其实我认为关键是要形成自己的编码规范，这个"规范"不仅仅指的是狭义的命名规则和代码格式，缩进，文件组织结构等.更关键的是，要形成一套有逻辑性，能自洽，有良性导向的一套思维模式，并时刻坚持遵守它，思考它，改进它.
　　这套思维模式你可以自由的去扩展，只要不偏离它的中心思想.比如我给自己扩展的一些要求:
　　1.函数一律使用动宾结构，如InitFactory，而不用FactoryInit，其实这两者没什么优劣，仅仅只是让自己习惯，以后思考和阅读自己代码的时候，能更快的带入过去的自己的思维，更快的理解自己的代码，同时找api也能节约一点时间.
　　2.html标签样式id小写开头，class大写开头，同理，其实也没啥原因，是个习惯.
　　3.描述一个事物的时候要区分是what it is(名词，形容词)还是what it can do(动词，动名词，动宾短语)比如doClose， 是某个事物的动作，closing，和 closed则代表它的状态
　　再是结构设计上的一些感觉了，这个比较抽象，不好用文字很准确的描述，大致意思是我会从一些纬度对功能进行切分，access business viewModel show interaction 等，不一定都能分的非常清楚，也不强求一个区分度很高的边际，但至少要有个模糊的定位.
　　如果能长期坚持下来，以后阅读自己的代码是非常容易的，即使是没有(少量)注释.
　　Ps:锤炼自己的这套思维模式的方法也很简单，也三点
　　多看代码，自己动手多写，多思考总结.