tcler's blog --- 其实我是一个程序员
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

{
    natural repugnant
    我们对于长期珍爱的信念，不要说反对，就是拿出来讨论一下也会引起本能的反感与憎恶。这个呢，大家应该都有感受。
    说的很抽象，我举几个具体的例子。比如你从小接受的思想，你认为他是天经地义的，不言而喻的正确，这个东西别人不
    要说反对，他一反对你固然生气，他不反对即使拿出来和你讨论为什么会这样你都会生气。有没有过这样的体会？
}

(结合经历过或看到过的例子):
* 比如 曾经认为C项目遵守linux code style是天经地义的，有人只是想讨论制定编码规范我就 产生本能的憎恶和反感:
  A: MD，有现成的不用，讨论/制定个P (嗯 是简单粗暴)
  B: 反方观点: 我们是一个单独的项目，凭啥就一定要用linux kernel的规范，我就喜欢RMS GNU的风格
   注:其实很多规范中大部分条款都是一致和相近的，大家反对的只是其中某一条(或几条)具体规定
  MtoB: 你不同意linux code style的哪个条款
  BtoM: “打印GNU规范并烧掉”的话很欠扁，还有把其他缩进偏好的人叫做“异端”
  MtoB: 嗯，除了这些还有哪些？
  BtoM: 没有了，其他都还好，其实我也不喜欢 GNU 的缩进风格(编辑效率低)

* 比如 有人说屏幕越来越大，把每行最大行长改为 100 or 120 列，我本能的气愤(但最后也找到一些*事实和理性*依据)
    1. 你让非洲的同事(仍在用淘汰掉的低分辨率的CRT显示器)怎么阅读你的代码(就是向后兼容嘛)
    2. 虽然屏幕大了一点，但是大家很多人都用 source insight 浏览代码，IDE 有左右边栏，这些都会吃掉显示器增长的部分
    3. 很多时候我们分屏比较代码 blablabla
      *source insight:(一款很牛的IDE，支持语义分析，直接点击代码里的解构体、函数名，就会准确的跳转到定义的地方)

    在争论/讨论的过程中，大家忘记了本能的抵触，开始理性的讨论起规范的由来、和怎样让代码更有利于阅读和维护

* 比如 有人认为应该用 tab 缩进，他女友认为应该用 4 空格缩进，后来互相觉得对方不可理喻、无法沟通分手了 -- <硅谷 第三季>

* 比如 有人指出其实 https://en.wikipedia.org/wiki/Programming_style#Spaces 里的描述是对的，三种写法对readability影响不大
    但是过于紧凑密集、和过多空格 仍然让很多人感到不舒服
    所以仅仅为了风格统一，选择使用第二种，大家也很快达成共识

* 比如，linux code style 里，network 子系统的注释风格坚持 /* (without newline)blabla
    这是纯属个人偏好，且因为强迫症不能妥协，；因此为了保持最大限度的风格统一(规范里network子系统里大家使用/* xyz)

    注: 如果经过讨论 纯属个人偏好的部分，希望没有强迫症的人*牵就*有强迫症的人
    注: 如果有两个强迫症的maintainer，都不愿意做妥协让步，那就某规范条款 在各自负责的模块内使用不同的标准,,

# linus 对network子系统注释风格的意见,和处理结果
https://developers.slashdot.org/story/16/07/12/2036201/linus-torvalds-in-sweary-rant-about-punctuation-in-kernel-comments
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting