语法高亮干扰代码阅读?

posted on 17 Feb 2014

17 Feb 2014 – sz home

最近折腾编辑器的时候,看到一篇文章:
A Case Against Syntax Highlighting
link

作者的观点是:
语法高亮弊多于利。

弊端:

1. 多种颜色会分散读者的注意力。
(本邮件的附件图片就是一个例子。)
(“快速阅读”能力越强的人,感受到的干扰应该越大吧。)

2. 语法高亮对代码的debug 并没有多大的帮助:
该内存泄漏的依然泄漏,该溢出的照样溢出,蹩脚的算法照样蹩脚。

3. 让人把更多的注意力放在了语法上,而不是逻辑。
(在容易出现拼写错误、语法错误的情况下,这就是个恶性循环。)
(感觉这一点是对应了用 MS Word 和 Latex 写文章的那种差别。)

4. 误导新人走弯路,并让人产生依赖
有语法高亮就_可能_不会刻意在意拼写和语法问题,这样就不能以_最
快的_速度养成正确的习惯。
如果从一开始学习的时候就有语法高亮,那么以后在没有的时候就会觉
得看代码非常困难。

好处:

1. 如果长篇的代码中,有一大段是被_注释_掉的,在有高亮的情况下,
就不会在读代码或者 debug 的时候浪费太多时间了。
其实“大段被注释掉的代码”就是一个错误的做法。如果这段代码还有什
么参考价值,就应该放着另外一个专供“参考”的地方。

2. 在c 语言中,= 和 == 经常会让人犯错。如果语法高亮能处分两者
的不同,就很有作用。
事实上几乎没有编辑器做这样的高亮区分。

这样,文章的作者就作出了总结…… 略。

这跟主流观点很不一样啊,我们以前的认识难道不应该是:
没有语法高亮?怎么做代码编辑器!

不过现在我觉得这文章说的还是有点道理的。

我还发现一个情况:

Linus Torvalds 说他用的是macroEmacs 的一种定制版,
(在kernel.org 上可以找到。)不仅没有语法高亮,
连undo 都没有……(说是macroEmacs 4.0.x 版本才有undo,
Linus 那个是基于那谁的3.9e 的。)

各位同学,你们怎么看语法高亮对 读写代码 的影响的啊?

google group link:
go


更新:

快速阅读的概念适用于代码阅读吗?

有种说法是,代码是为了给人看的,可以编译运行只是它的附带功能。

如果它的主要功能就是_给人看的_,那代码在语言交流上的定位
就和传统语言是一样的。只是代码用的是某种程序语言。

英语对我们来说是一门外语,那就把c 语言当成另一门外语咯。只是
c 语言向英语借用了一些元素而已。

用实践来证明

其实我也是这两天才发现“语法高亮会影响阅读”这个说法的,
我很有兴趣实验一下关掉高亮,我的代码阅读效率是提高了还是降低了。

颜色确定起到了辅助作用,但是是积极作用,还是消极作用,只有让
我自己试过3、5个月之后,我才能知道……

只是我怀疑“高亮可以辅助定位_有用信息_”这个概念,是我臆想出来的,
或者是其他人暗示、灌输给我的,我要亲自尝试过才知道真假。

我要选择 red pill,去所谓的的真实世界看一看,然后才判断哪里
才是幻境。

语法高亮是用颜色来区分内容吗?

在代码中,注释和执行代码用颜色来区分,确确实实有助于理解,
这是“与内容相关的”区分;

但是关键词和变量用不同颜色,就应该是“与内容无关的”了,
这只是 与语法相关。

例如,一句话,把动词和名词用不同颜色区别,肯定会降低
理解整句话内容 的速度。
文章中,爱丽丝的那张图片也是这个意思。
(当然,动词和名词用分别标色,是利于分析语法结构的。)

高亮影响debug 吗?

读代码也是一种debug 的方法。

我觉得debug 不仅仅是用调试工具运行程序,读代码也可以发现程序
中存在的问题呀。

比如,
通过读代码,我发现这个地方算法很低效,想办法改……
…可能会出现栈溢出,改……
…忘记用free/delete 了,加上……

高亮为什么可能会使新手走弯路?

新人学编程最核心的就是 学拼写和语法。

就像我们当年学语文一样,先学写字和造句,然后才是作文。
不会“写字”和“造句”,程序就不能编译,不能编译的程序就没有逻辑
可言。
(这里认为,if…else…,for,while,def 等等,属于“造句”。)

我们写作文、写论文,如果经常需要查字典,扰我们的思路的思路肯定
会受到极大的干扰,整个人就烦躁了。

但是如果用一门不经常使用的语言写代码的时候,情况可能就不一样了:
是else if 还是elif?要用endif 吗?create 还是 creat?……
我们好像也不是特别害怕,因为有语法高亮嘛,试一下就知道了。

但是,这些疑问和不确定 不影响我们的编程思路吗,不消耗我们的
精力吗?

所以新学一门语言,如果不在意这些细节,必然要走弯路的。

高亮为什么会干扰编程思路?

有了扎实的基础,“应用”的时候,我们根本不会为语法的正误纠结。
就算是写错了,也不用,更_不应该_纠结。

先以最流畅的姿势把思路写出来,再让编译器去帮我们找语法错误。

语法高亮在这个时候起到的作用无异于:
“喂,你的‘士’写成了‘土’,快改过来!”
“这里应该用逗号,你怎么写个句号?!!”
……

我不把它拍死就是我脾气好!

既然高亮没用,notepad 也是不错的选择咯?

我对记事本的意见在于:
插入、删除、查找、复制、粘贴、移动光标等等的方式太麻烦了。
还有,它的默认字体好像不是_等宽_的。