程序员吐槽Matlab代码：注释比代码长3倍，科学家写的代码有多野？

在程序员圈子里，Matlab一直是个神奇的存在。搞科研的视若珍宝，写代码的避之不及。最近，一位名叫Andre的开发者分享了一段来自同事Jude的Matlab代码，瞬间在技术社区引发热议——不是因为代码有多精妙，而是因为这段代码的注释，简直比代码本身还要精彩。

事情是这样的：Andre的团队需要用Matlab管理实验场景，任务本身不复杂——生成一组参与者专属图片，存进数据库，之后能引用就行。但偏偏在他们用的数据库产品、Matlab许可证和各种限制的交汇处，他们发现：这事儿居然没有一条好走的路。

这时候，同事Jude站了出来，留下一句经典台词："别担心，我能凑合着搞一个出来。"然后，就有了下面这段让程序员们集体沉默的代码。

这段代码到底有多野？

咱们先看看这段代码的注释风格。变量名是缩写，注释是意识流，逻辑是螺旋式。比如这个：

nMk = 1; %counting non-response triggers, this cycles with each trial

翻译一下就是："nMk等于1，用来数非响应触发器的数量，这个变量会随着每次试验循环变化。"听起来还挺正常？别急，往下看。

紧接着的注释是："it's kinda roundabout, but the only recognisable part is the response, yet I refer to it only by elision, and instead count the stimuli to reconstruct the pattern"——"这有点绕，但唯一能认出来的部分是响应，不过我偏不直接说它，而是通过数刺激来重建模式。"

看到这儿，不少程序员已经露出了"地铁老人看手机"的表情。这哪是写代码，这是写诗啊。

注释里的心路历程

更绝的是，这段代码的注释完整记录了一个程序员（或者说科研人员）在写代码时的内心戏。比如这个case 1的分支：

case 1 %an almost reliable stimulus

"一个几乎可靠的刺激"——注意这个"几乎"，充满了不确定性的美感。然后代码检查触发器是不是'S1'，如果是，就把它改名为'cross'，然后进入下一个状态；如果不是，就记下"miss"，然后跳到响应状态。

注释里写着："it must be a non-response"（这必须是一个非响应），结果else分支里写着"except when it is not"（除非它不是）。这种自我否定的幽默感，简直可以入选程序员段子大全。

到了case 2，注释变成了"usually reliable"（通常可靠）。"通常"这个词用得妙啊，既表达了信心，又给自己留了退路。然后代码检查'S1'，如果是，就命名为'face'，记下位置；如果不是，就把整个试验标记为删除，记下miss，然后跳到响应。

注释里还特别贴心地写着："trailing triggers at the end should be ignored"（末尾的多余触发器应该被忽略）——看来作者已经被这个问题坑过不止一次了。

最精彩的部分来了

case 3的注释直接封神："this one is not reliable, and sometimes is duplicated instead of missing"——"这个不太可靠，有时候会重复而不是缺失。"

然后代码开始处理这种"不太可靠"的情况：如果是'S1'，先命名为'empty'；然后检查下一个是不是也是'S1'，如果是，就进入一个while循环，数一数到底有多少个多余的触发器。

注释里写着："and then count how many excess triggers are actually here"（然后数一数这里到底有多少多余的触发器）。紧接着是："nExcess = 1; %definitely one here already"（nExcess等于1，这里肯定已经有一个了）。

这种"肯定"的语气，配上前面"不太可靠"的铺垫，形成了一种奇妙的喜剧效果。

最后，代码把整个试验标记为删除，注释解释道："this overwrites the same positions several time, but the important part is to get the preceding two, because I don't know which one of them is correct one, so I delete the whole"——"这会重复覆盖同一个位置好几次，但重要的是把前面两个也删掉，因为我不知道哪个才是对的，所以干脆全删了。"

程序员们的集体共鸣

这段代码被分享到技术社区后，迅速引发了程序员们的集体共鸣。有人评论说："这注释写得比我的代码还清楚。"也有人表示："这就是我写代码时的真实状态——一边写一边怀疑人生。"

更有意思的是，不少科研背景的程序员表示感同身受："在实验室里写代码就是这样，没人教你软件工程，能跑就行。"

还有程序员从技术角度分析："这段代码其实反映了一个很现实的问题——当工具不顺手的时候，你只能靠各种hack来凑合。Jude能在这种条件下把功能实现出来，已经算是本事了。"

确实，从功能角度看，这段代码虽然看起来绕，但注释里每一步都说明了"为什么要这么做"。它可能不是最优解，但它是作者在当时的约束条件下能找到的可行解。

代码之外的故事

其实，这段代码背后折射出的，是科研编程和工程编程之间的巨大鸿沟。科研人员写代码，目标是"验证一个想法"；工程师写代码，目标是"维护一个系统"。两者的思维方式完全不同。

科研代码追求的是"能跑出结果"，工程代码追求的是"可读、可维护、可扩展"。Jude的代码明显属于前者——它完美地完成了任务，但它的可读性，嗯，全靠注释撑着。

有程序员调侃说："这段代码告诉我们，注释不是写给编译器看的，是写给下一个接手的人看的。而Jude显然很懂这个道理。"

还有人说："如果每个程序员都能像Jude这样把思路写在注释里，那代码评审会容易很多。"

当然，也有较真的程序员指出："这代码要是拿到我们组来review，估计会被打回去重写。"但立刻有人反驳："人家是科研团队，能用就行，你要求那么高干嘛？"

这场关于代码风格的争论，最后演变成了"科研代码vs工程代码"的大讨论。有人总结道："科研代码的终极目标是发论文，工程代码的终极目标是上线。目标不同，标准自然不同。"

而Jude本人，据说看到这段代码被疯传后，只是淡淡地说了一句："能跑就行。"

这句话，大概就是科研编程的最高境界吧。