先说结论：“二分法命题比较有得战、比较热闹；若像下面这样去考量各种层面的
话，会很无聊 XD 。”
# 从 电脑科学 的角度来看
所谓“写程式”的“写”，在抽象意义上即是“表达(express)” ；每种实用的语
言多半有其强项与短处，也就是方便与不方便的用途。
例如说，用 程式语言 来表达计算(computation)过程 ，尤其是表达给电脑看的计
算指令，通常来说会比用 自然语言 来得方便。
用 自然语言 (配合科学/数学符号) 来描述、解释问题，尤其是表达给人脑看的脉
络上下文(context) ，通常来说会比用 程式语言 来得方便。
是故，如果一个问题(problem) 是简单(simple)到可以从其
计算解决方案(solution)去反推出问题的全貌，那么，的确用程式语言去描述计算
过程就可以了，也就是“不太需要去写注解”。
反之，如果一个问题的复杂度高，或其脉络是难以用程式语言去描述的，那么，就
可以用自然语言这个更适合的工具，去描述该问题的脉络，也就是“有写注解的价
值”。
有兴趣的话，可以参考 DSL/GPL 的观念:
* https://en.wikipedia.org/wiki/Domain-specific_language
* https://en.wikipedia.org/wiki/General-purpose_language
# 从 软件工程 的角度来看
前面板友 ThxThx 在推文 [1] 里点出的文章，有更深入完整地探讨这个方向。
* http://antirez.com/news/124
* https://www.reddit.com/9m6ahs
Hacker News 上也讨论过 antirez 的那篇文。
* https://news.ycombinator.com/item?id=18157047
[1]: https://www.ptt.cc/bbs/Soft_Job/M.1546056944.A.99E.html
以下是对原文的摘要，加上简略的、我的解读与看法；作者 antirez 把注解分为
9 大类如下，且主张：“前 6 大类是相对有正面价值的，后 3 大类则有疑虑
。”
> * Function comments
“函式注解”，可以想成“接口(interface), API ”注解。
> * Design comments
设计蓝图、大方向的注解。
> * Why comments
相对于描述“如何(how)”的程式码 ，解释“意图、原因”的注解。
> * Teacher comments
深入解释“问题的脉络/领域(domain)”的注解 ，例如，某数学公式的由来
。
> * Checklist comments
列出“提醒/警示”的清单注解 ，例如，帮助后人避免踩中技术细节的地雷。
> * Guide comments
“导读”注解。
> * Trivial comments
解释“不言自明”之事的注解；读这类注解所需要花的精神，不见得比直接读程式码
来得少，且不见得能帮助读者更了解此程式要解决的问题。
> * Debt comments
技术债注解；或许应该以 issue/bug 的方式记录技术债，而不是藏在程式码
里。
> * Backup comments
以 备份 为目的，把旧的程式码以注解的方式留在程式码档案里。
易言之，不同型式的注解有不同的用途与价值。
# 从 人体工程 的角度来看
相对于 软件工程 ， 人体工程 XD 是更困难的。
真正的问题通常不是技术问题，而是认知、环境、历史等脉络上的问题，尤其是那
些“没有被说出来 / 没有便利的共同语言去表达” 的东西。
那些东西对轻重缓急的取舍拿捏有极显著的影响与冲击，却又常常是无影无形难以
捕捉、表达、沟通。
(“人体工程”离原主题太远了，就此打住。)
[编辑补充] 就“人体工程”这个题目，可以参考 qrtt1 写的这篇:
https://www.ptt.cc/bbs/Soft_Job/M.1546144956.A.439.html
# 结论
扁平化、二分法命题比较有得战、比较热闹；若像上面这样去考量各种层面、脉络
的话，会很无聊，很难战 XD 。