刷到银杏独占一门的生物学谣言被澄清，哑然失笑。咱计算机界何尝没有这类“祖传真理”？当年自学汇编时，总听人说“高级语言淘汰底层”，结果修老设备驱动时，抱着Z80手册啃到凌晨三点。还有“代码越短越优雅”，见过为省三行字把逻辑绕成毛线团的“神作”。技术传播最怕简化成口号，失了分寸。诸位同仁，你被哪些编程“常识”坑过？求分享避雷～（我先坦白：曾坚信“注释越多越专业”，直到维护到注释写“此处很妙”的祖传代码……）

“注释越多越专业”这个迷思，我太熟悉了——刚入行那会儿甚至专门写过脚本统计注释覆盖率，以为能当KPI用。后来在温哥华一家老派嵌入式公司实习，接手一段80年代遗留的C代码，注释密密麻麻，结果十有八九和逻辑对不上。最离谱的是某处写着“此处很妙”，实际是绕过硬件bug的临时补丁，作者可能觉得机智，但十年后的人根本不敢动。

其实注释的有效性，关键不在数量而在信息熵。Knuth在《Literate Programming》里早就区分过：解释“为什么”（why）的注释有价值，复述“做什么”（what）的往往是噪音。比如Linux内核里那些描述设计权衡的注释，比单纯标注函数功能有用得多。反观某些开源项目，自动生成的docstring堆成山，反而掩盖了真正需要理解的上下文。

从维护成本看，注释和代码一样需要同步演化。NASA的软件工程手册里明确说：“过时的注释比没有注释更危险。” 我们组去年重构一个支付模块，删掉了40%的注释——不是因为它们冗余，而是发现其中17%与当前逻辑矛盾，留着反而误导新人。

不过话说回来，完全不写注释也太极端。我在画爵士乐手速写的间隙常想：好的注释应该像蓝调里的call-and-response，不是重复旋律，而是在关键转折处点出情绪张力。比如解释“为何这里不用标准库而手写循环”，或者“此算法牺牲精度换实时性”。这种注释，一行胜百行。

btw，最近读到Google内部一份代码审查指南，提到他们用ML模型预测注释的“困惑度”（perplexity），高困惑度的注释会被标记复查——本质上还是在衡量信息增量。技术传播怕口号，注释文化也一样。与其追求“多”，不如问一句：这段注释五年后还能帮人避开坑吗？

（刚煮了杯Ethiopian Yirgacheffe，突然想到：注释大概就像咖啡的酸香，有则提神，滥则涩口……）