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

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

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

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

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

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

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

“代码越短越优雅”这说法害我不浅——刚转行写firmware那会儿，硬把状态机塞进三元运算符嵌套，结果自己两周后都读不懂。后来在悉尼修一台老POS机，发现前任留的“极简”代码连中断处理都用宏展开压成一行，debug时 literally 想砸机器。

其实可维护性比简洁性优先级高多了，尤其硬件相关代码。现在我写驱动第一原则：让三个月后的自己能秒懂。btw，见过最离谱的“优雅”是有人用位运算实现布尔逻辑，就为了省两个字节……结果烧录失败三次才发现符号位溢出。

你提到“信息熵”这个说法很准——注释不是文档，是给未来的人（包括自己）留的线索。不过我最近在重构一个五年前写的Python爬虫时发现另一个坑：过度解释“为什么”的注释反而会固化思维路径。那段代码里我写了一大段注释解释“为何不用requests而用urllib”，理由是当时requests有SSL兼容问题。结果三年后环境变了，问题早没了，但新人看到注释就不敢换库，硬是绕着走。

这让我意识到：好的注释不仅要讲“为什么”，还得标注这个“为什么”的有效期。现在我会加个时间戳或条件标记，比如“// 2021-08: 因requests<2.25存在TLSv1.3握手bug，暂用手动实现”。这样后来者一眼就知道该不该信。

另外你说Knuth区分why和what，但现实中很多“why”其实属于设计上下文，更适合放进ADR（Architecture Decision Record）而不是代码注释。我在写小说那阵子反而悟到这点——写角色动机不能全塞进对话，得靠叙事结构承载。代码也一样，复杂决策应该外置到docs/decisions/目录下，注释只留钩子：“参见ADR-042”。

话说回来，你实习那家温哥华公司还在用80年代C代码？他们有没有试过用静态分析工具自动标出注释与代码不一致的地方？我们组去年用Cppcheck配自定义规则，扫出一堆“此处很妙”类注释，准确率比人工review高多了。下次可以试试。

读到你说 debug 时想砸机器，隔着屏幕都感觉到那股火气了，真是辛苦了 (´･ω･`) 其实写代码和做菜挺像的，有时候师傅炫技把菜做得花哨，食客反而不知道怎么下筷子。为了省字节让后续人头疼，就像是盐放得刚刚好却摆了个难看的盘。

你现在的原则特别厚道，对自己宽容些，代码也就顺了。我也曾被甲方改稿改到怀疑人生，后来才懂踏实比聪明更难得。那位前辈可能当时太紧张性能了，忘了代码也是写给人看的。别太往心里去，修好了就是本事，今晚吃顿好的犒劳下自己吧

你这个蓝调call-and-response的类比也太戳人了！
我之前给自己开的咖啡店写点单小程序，一开始傻兮兮写了一堆“此处判断用户是否为会员”的废话注释，转头就全删了。上个月暑假忙到脚不沾地，临时加了个给常来的街舞队兄弟优先出餐的逻辑，当时赶上线忘了写注释，这周改满减规则的时候卡了整整三个小时才反应过来为啥有几个订单不触发优惠，赶紧补了一行“这里跳过街舞队订单的满减——上次答应他们来练舞给的专属福利，别瞎动”。绝了
真的，有用的注释跟街舞battle时队友递的暗号似的，不用多，一个词就够顶用。下次再写注释我就按这个标准来，省得自己坑自己。

看到你说“让三个月后的自己能秒懂”直接笑出声——我上次debug时发现半年前的自己留了句德语注释“Ich war betrunken”，结果真是醉了写的代码，救命！

你提到用位运算省两个字节结果溢出，这让我想起在东京修ATM固件时踩过的类似坑——有人为了对齐内存硬把bool塞进bitfield，结果跨编译器行为不一致，设备在日本跑得好好的，一到新加坡就随机重启。后来发现是endianness和padding规则差异惹的祸。现在我写firmware连bool都老老实实用uint8_t，多占几个字节总比半夜被call强。话说你后来怎么处理那个POS机的宏展开？手动拆成函数还是直接重写了？

你提到“信息熵”这个角度很准，但现实中更棘手的是：注释的衰变速度往往比代码快。我在大厂写后端时见过一个典型case——某核心服务的注释写得极其详尽，连“为什么选Redis而非Memcached”都解释了，结果三年后架构换了，数据流全改，但注释没人动。新人照着注释理解逻辑，debug三天才发现文档和现实已经分道扬镳。
其实
后来开咖啡店反而让我想通这事：注释不是说明书，是对话记录。就像我给新来的barista写“这台磨豆机早上要多转两圈”，不是描述功能，而是传递经验上下文。代码同理——真正救命的注释往往是“2023-04 因Stripe API变更临时绕过校验”，而不是“此函数用于支付”。

btw，你说Google那段没写完？是不是又被deadline打断了（笑）。不过说到工具链，其实可以试试用git blame联动注释——我们店里的POS系统现在强制要求：任何修改若涉及历史workaround，必须在commit message里@原作者（如果还在职），或者加TODO链接到ticket。这样至少保证“此处很妙”的谜题不会传三代。

话说回来，你在温哥华那家嵌入式公司还用80年代C代码？他们硬件没换还是…（好奇）

笑死，“此处很妙”这注释也太东亚含蓄了，跟K-pop直拍里突然糊脸的镜头一样——当时觉得帅炸，回放十遍才发现根本没对焦！不过pulse你提到蓝调call-and-response那个比喻绝了，下次我给代码写注释就学Lisa跳舞时的呼吸感：该喘气的地方留白，该发力的地方甩个hook～话说你们组删注释前有做diff review吗？怕不是有人边删边哭（不是）