[OT] 语法高亮会干扰代码阅读吗？

[Ken CC]

最近折腾编辑器的时候，看到一篇文章：
A Case Against Syntax Highlighting
Http://www.linusakesson.net/programming/syntaxhighlighting/

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


弊端：
---
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 的。）


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


额，元宵节快乐！

-ken

[Zoom.Quiet]

无法同意更多

> --
>
> ---
> 您收到此邮件是因为您订阅了 Google 网上论坛的“TopLanguage”论坛。
> 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 pongba+un...@googlegroups.com。
> 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。



--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://zoomquiet.io
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

[Ken CC]

On Fri, Feb 14, 2014 at 10:17:47PM +0800, Ken CC wrote:
>
> 最近折腾编辑器的时候，看到一篇文章：
> A Case Against Syntax Highlighting
> Http://www.linusakesson.net/programming/syntaxhighlighting/
>
> 作者的观点是：
> 语法高亮弊多于利。
>
>
> 弊端：
> ---
> 1. 多种颜色会分散读者的注意力。
> （本邮件的附件图片就是一个例子。）
> （“快速阅读”能力越强的人，感受到的干扰应该越大吧。）

刚才忘记加附件了……



-ken

[Doyle]

因为习惯高亮了，以为如果没有高亮会很麻烦。
不过回想一下，最早小霸王学习机、文曲星上的basic都没有高亮; 在纸上手写代码没有高亮; 学校破机器上的turbo c没有高亮，也都一路过来了。
也许依赖高亮只是心理作用吧。
不过，如果编辑器支持高亮我还是义无返顾的开启高亮的。

[Zhang Xiang]

不同意，还是有语法高亮比较好

--

[Xpol Wan]

> 语法高亮对代码的debug 并没有多大的帮助：

高亮是提高阅读的便利吧。不是用来debug的。

就像说冰箱不能用来帮助煮鸡蛋一样。

Best Regards!

Xpol Wan
// There is a better way!

[Xpol Wan]

PS，楼主，情人节、元宵节不去过。在这里谈技术，简直就是“双节棍”啊。

Best Regards!

Xpol Wan
// There is a better way!

[Xiong Zhou]

针对代码来谈快速阅读能力有些不妥，纯文本和代码不是一回事。

我认为语法高亮可以辅助快速定位所需信息，还是很有必要的。颜色也是一种可以利用的信息，省去了人脑parse的过程。

[iridium]

 是的。

自从用了高亮后，我再也不用非高亮了。

Best Regards,
Iridium

-----------------------------
From: Xiong Zhou <xion...@gmail.com>
Sent: Fri, 14 Feb 2014 23:28:41 +0800
To: pon...@googlegroups.com 
Subject: Re: [TL] [OT] 语法高亮会干扰代码阅读吗

[Jawley]

“1. 多种颜色会分散读者的注意力”

与内容无关的颜色会分散读者的注意力。与内容有关的则不会，能够帮助内容理解的就更不会。

“2. 语法高亮对代码的 debug 并没有多大的帮助”

如 Xpol Wan 所说，语法高亮本来也不是用来 debug 的。

“3. 让人把更多的注意力放在了语法上，而不是逻辑”

恰恰相反，语法问题有高亮来帮忙，可以让人消耗更少的注意力，把更多注意力放在逻辑上。

“4. 误导新人走弯路，并让人产生依赖”

新人学编程最核心的是学逻辑思维，不是拼写和语法。死磕语法才是走弯路。

而且 3 和 4 居然是自相矛盾的。

一股浓浓的老古板味道。不如说，大家都应该先学汇编，否则如果一上来就学高级语言，万一以后没有高级语言用了怎么办。

Jawley

Forwarded message:

[Ken CC]

On Fri, Feb 14, 2014 at 11:14:33PM +0800, Zhang Xiang wrote:
> 不同意，还是有语法高亮比较好
>

老板，有没有理由，来两毛钱的。

:-)


-ken

[Ken CC]

On Fri, Feb 14, 2014 at 11:22:21PM +0800, Xpol Wan wrote:
> > 语法高亮对代码的debug 并没有多大的帮助：
>
> 高亮是提高阅读的便利吧。不是用来debug的。
>

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

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


然后就是 高亮是否能提供阅读便利的问题了……


-ken

[Ken CC]

On Fri, Feb 14, 2014 at 11:28:41PM +0800, Xiong Zhou wrote:
> 针对代码来谈快速阅读能力有些不妥，纯文本和代码不是一回事。
>

其实，写邮件的时候，_快速阅读_这个词就是在我脑子闪了一下，
我自己都觉得奇怪。不过我还有找到理由了，
有种说法是，代码是为了给人看的，可以编译运行只是它的附带功能。

如果它的主要功能就是_给人看的_，那代码的语言交流上的定位
就和“纯文本”是一样的。只是代码用的是某种程序语言，“纯文本”
用的是英语、汉语或者其他。
英语对我们来说是一门外语，那就把c 语言当成另一门外语咯。只是
c 语言向英语借用了一些元素而已。

（确认一下，你说的“纯文本”是指自然语言构成的文字集合，
“代码”是程序语言构成的。
但是通常来讲，我们所说的代码文件是纯文本的。）


> 我认为语法高亮可以辅助快速定位所需信息，还是很有必要的。
> 颜色也是一种可以利用的信息，省去了人脑parse的过程。

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

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

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

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

哈哈，我一点也不偏激。


-ken

[Zoom.Quiet]

点赞！
实践出真知！

Zoom.Quiet from N7108

[Zhang Xiang]

你拿记事本打开一个源代码看看感觉一下吧。

[Mi Vman]

个人习惯问题。
如果代码结构清晰，高亮不高亮影响不大。
眼睛舒服了，脑子也轻松。
---------------------------------------------
在 2014年2月14日星期五UTC+8下午10时17分47秒，ken.cc写道：

[Ken CC]

On Fri, Feb 14, 2014 at 11:02:55AM -0600, Jawley wrote:
> “1. 多种颜色会分散读者的注意力”
>
> 与内容无关的颜色会分散读者的注意力。与内容有关的则不会，
> 能够帮助内容理解的就更不会。

在这里“与内容相关”好像有点难定义啊。

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

但是关键词和变量用不同颜色，就应该是“与内容无关的”了，
这只是 与语法相关。
例如，一句话，把动词和名词用不同颜色区别，肯定会降低
理解整句话内容 的速度。
文章中，爱丽丝的那张图片也是这个意思。
（当然，动词和名词用分别标色，是利于分析语法结构的。）

>
> “2. 语法高亮对代码的 debug 并没有多大的帮助”
>
> 如 Xpol Wan 所说，语法高亮本来也不是用来 debug 的。
>

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

> “3. 让人把更多的注意力放在了语法上，而不是逻辑”
>
> 恰恰相反，语法问题有高亮来帮忙，可以让人消耗更少的注意力，
> 把更多注意力放在逻辑上。
>
> “4. 误导新人走弯路，并让人产生依赖”
>
> 新人学编程最核心的是学逻辑思维，不是拼写和语法。死磕语法才是
> 走弯路。
>
> 而且 3 和 4 居然是自相矛盾的。
>
> 一股浓浓的老古板味道。不如说，大家都应该先学汇编，否则如果一
> 上来就学高级语言，万一以后没有高级语言用了怎么办。

我想3、4 应该不是矛盾的，只是顺序放错了。
正确的顺序是，先学习，再应用。

4.
新人学编程最核心的就是 学拼写和语法。
就像我们当年学语文一样，先学写字和造句，然后才是作文。
不会“写字”和“造句”，程序就不能编译，不能编译的程序就没有逻辑
可言。
（这里认为，if...else...，for，while，def 等等，属于“造句”。）


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

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

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

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


3.
有了扎实的基础，“应用”的时候，我们根本不会为上述情况纠结。
就算是写错了，也不用，更_不应该_纠结。

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

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

我不把它怕死就是我脾气好！


-ken

[Ken CC]

On Sat, Feb 15, 2014 at 11:53:37AM +0800, Zhang Xiang wrote:
> 你拿记事本打开一个源代码看看感觉一下吧。
>

看看之后的感觉是：很不习惯而已。

我对记事本的意见更多在于：
插入、删除、查找、复制、粘贴、移动光标等等的方式太麻烦了。


-ken

[Bowen Ma]

不会干扰到，还有些许帮助吧

-- 

Bowen Ma

Sent with Sparrow

[lor fal]

在阅读legacy code的时候没有语法高亮怎么活啊~

语法高亮可以在视觉上对代码块进行分块处理，一眼看过去更清晰，更容易定位。

--
Best regards,
LORFAL

[郎咸武]

从看到此帖开始把vim的高亮去掉了，到现在已完全适应黑和白，加上高亮后感觉有点晃眼。从此不在担心远程连接服务器没有高亮显示的情况了。

--

---
您收到此邮件是因为您订阅了 Google 网上论坛的“TopLanguage”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 pongba+un...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

--
只为成功找方法，不为失败找理由

[Luo, Carrot]

合适就好，晃不晃眼无非是颜色方案的问题。 高亮本身就是为了让眼睛聚焦真正重要的东西，如果没有高亮，眼睛会很痛苦，工作时间也就成问题了，头晕眼酸神马的

--

---
您收到此邮件是因为您订阅了Google网上论坛中的“TopLanguage”论坛。
要取消订阅此论坛，并停止接收其发来的电子邮件，请发送电子邮件至pongba+un...@googlegroups.com。
如需了解更多选项，请访问https://groups.google.com/d/optout。

[郎咸武]

从另一角度考虑，这应该是有意识行为和无意识。虽然代码高亮显示没有了，但在文件中查找某个关键字时，高亮显示查找的关键字还是非常有用的。

--
只为成功找方法，不为失败找理由

[Leo]

谁知道emacs gdb模式下，如何高亮显示gdb的输出，尤其是bt和info threads

[qihang zhang]

怎么看大家的回复就好像不用语法高亮的是主流？！

大家平常真的不用语法高亮么？！

反正我是对这篇文章（lz分享的）一点也不感冒，我不但要用高亮，还要用好看的，养眼的高亮，一个看烦了还要换另一个 ：）

给同好者推荐https://github.com/chriskempson/tomorrow-theme ，最近在用，很不错 ：）

--

[月忧茗]

别人我不清楚， 反正我离不开语法高亮。

这么说吧，以前我是一个VIM死忠，

后来用了IDE，做project再也不用VIM了。

如果LZ你觉得 没有高亮能提高你的生产力， 那么就把高亮关了吧。

如果你能坚持，请给我发个email。

--

My GitHub
https://github.com/yueyoum

My Blog
http://codeshift.org

[Yongwei Wu]

顶上。有IDE用IDE，没有IDE或者偶尔IDE不给力时用Vim。没有Vim，Notepad上也没什么大不了。但千万别跟我说Notepad是最好的工具！

Wu Yongwei
URL: http://wyw.dcweb.cn/

[faen zhang]

能不能做个投票?

我个人喜欢代码高亮, 可以帮我快速的定位信息和快速的过滤信息

[Yuuki Galaxy]

最简单的例子，在字体不好区分的情况下，两个单引号，一个英语双引号，一个中文双引号，就得靠语法高亮区分。

[CPluser]

还是觉得IDE更智能 提高效率

[Xinyu LIU]

说个亲身体会。有一阵，我在Emacs中装了auto complete。结果我发现如果一个symbol命名的不好，或者干脆拼错了。

auto complete会帮助你继续用这个不好的命名，或传播这个错误。tab太cheap了，于是就忽略了命名和拼写的问题。

用了几个星期后，我发现我的记忆力下降了，很多API忘记叫什么，因为太依赖auto complete了。

于是我把auto complete关了。结果我一下子发现了很多命名中的拼写错误，并且我发现很多不好的命名。更加令我吃惊的是，其他同事想不起来的东西，我能清楚地记得。

我仔细观察了这个现象，Eclipse等现代IDE带来的效率提高，是个很表面的效率提高。表面上程序员敲代码快了，IDE帮着写代码。

但由于太cheap了，程序员开始懒得记忆和思考。而思考和记忆的下降，完全抵消掉了敲键盘的效率提高。

在我们组中，其他人都是用Eclipse + ADT，而我仍然用emacs和一些命令行。但是我观察到我的效率会高于其他同事。

我对Emacs的各种扩展很快形成了自己的评价体系，说起来比较的中庸：扩展和工具应该帮助减少简单的重复劳动，但不应该取代我或者干扰我的记忆和思考。

所以我使用Theme，但是常年使用那个classic的，我使用yasnippet，但是不用auto complete。我左右分屏，但是不用cedet的那个花哨窗口。

最后一个，也是最重点的：

我用emacs，也同时用打废的A4纸背面和铅笔。

Larry, LIU Xinyu
https://sites.google.com/site/algoxy/
https://github.com/liuxinyu95/AlgoXY

[robin...@gmail.com]

Hi all，

看了这么多讨论，有一个疑问：

能否在高亮和非高亮这个问题上，抽象出一个心理学，或者说哲学上的原理呢？

发自 Windows 邮件

[houzhanfeng]

一般来说 auto complete 分为几个层级：

1. 关键字提示，这个不会导致您所说的 “传播错误”，但仅提示关键字意义不是太大，这个实现起来很容易。
2. 输入过的单词提示，这个会导致 “传播错误” ，实现起来也很容易。很所谓 IDE 或编辑器，特别是一些针对 js 的前端编辑器常是这种方式，比如 Sublime。
3. 真正的 “智能提示”，是根据您所用语言的语义提示的，比如提示对象的成员变量，这个也有可能导致 “传播错误”。但是通常能做到这个的 IDE 也有很方便的重构功能，比如 VS。

我认为用那个工具对编码速度根本没有什么影响，编程又不是速录。

我常用 vs/sublime/还有我自已写的一个编辑器，偶尔用 xcode/eclipse。

 原始邮件 

发件人: Xinyu LIU<liuxi...@gmail.com>

收件人: pon...@googlegroups.com<pon...@googlegroups.com>

发送时间: 2014年3月12日(周三) 11:44

主题: Re: [TL] Re: [OT] 语法高亮会干扰代码阅读吗？

[qiaojie]

用auto complete可以减少我们的记忆量，但不是什么坏事，也无关效率。记不记得一个API的名字对编程来说无关紧要，重要的是API背后的功能和设计，过分拘泥于细枝末节反倒不利于思考。

[郎咸武]

个人觉得常用的API名字都记不住的话，确实不怎么好。 如果有人在群里或户外聚会或.....讨论时。就是想不起API名字交流肯定受影响。有次我就想不起来反编译Erlang代码的参数。最后只能手机查阅了一下。

只为成功找方法，不为失败找理由

[Frank Ren]

Eclipse的refactor很有用。如果用vim，很多应该做的refactor，比如java class重命名，用vim做起来太难，干脆就放弃了。Eclipse的Maven插件也很好用，虽然命令行也可以做，但是处理依赖关系冲突的时候从Eclipse Maven插件上操作顺手多了。用了Maven 之后，对于开源的软件包，可以直接跳转到函数定义上，比用vim方便多了。Log4j，SLF4j，Apache Commons，这些依赖的包一大堆一大堆的，我反正记不了这么多，有编辑器提醒，需要的时候还能查源码，很方便。

我曾是vim的重度用户，自己也写了几个小插件现在还在用，但现在基本上只用来写小工具和脚本以及做TODO list。做项目的时候还是用IDE，Intellij/PyCharm/Eclipse等等都用过。曾经以为写Python用VIM最方便，但是用PyCharm之后，发现对发现一些语法问题大有帮助，特别是快速开发的时候，测试度覆盖度很低，有些问题到运行时才发现，但是如果用IDE，直接就发现了。

另外，IDE的警告也很有用，遇到过几次花了许多时间查的问题，后来发现只要多花点时间把所有的警告都处理掉，这些小问题自己就不见了。比如变量定义了但没有使用，变量作用范围冲突等等。

--

Frank

[葛光乐]

怎么单独屏蔽这个话题

就这么个语法高亮，讨论了多长时间了啊！！！！！！！！！！！！！！！！

[jyf]

On Wed, Mar 12, 2014 at 12:44:32PM +0800, qiaojie wrote:
> 用auto
> complete可以减少我们的记忆量，但不是什么坏事，也无关效率。记不记得一个API的名字对编程来说无关紧要，重要的是API背后的功能和设计，过分拘泥于细枝末节反倒不利于思考。

如果连名字都记不住 恐怕功能更记不住吧
到时候思考与设计的时候又怎么知道可以使用这个api呢？

除非是你日常天天用的 但是这种情况下 你又怎么可能记不住那个api的名字呢

所以我觉得减少记忆量这个功能不是太好 当然我也不反对用
因为现实情况是许多时候就是编程 没有思考 怎么快怎么来

另外的情况是大工程或者语言设计问题导致的api名字他不简洁
经常用的情况下 谁不希望能快点敲出来那代码呢 说到底 还是我们
大脑的思考比手敲代码快 用auto complete 可以稍微减少大脑
等待的时间 以获得思考的一贯性 也许将来用脑机接口编程了以后
就不需要这些了

[葛光乐]

怎么单独屏蔽这个话题

就这么个语法高亮，讨论了多长时间了啊！！！！！！！！！！！！！！！！

--

---
您收到此邮件是因为您订阅了 Google 网上论坛的“TopLanguage”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 pongba+un...@googlegroups.com。

要查看更多选项，请访问 https://groups.google.com/d/optout。

[Xinyu LIU]

gmail的话，你可以用m来mute这个thread。

Larry, LIU Xinyu
https://sites.google.com/site/algoxy/
https://github.com/liuxinyu95/AlgoXY

[月忧茗]

上面说的 emacs 自动补全 导致前面的拼写错误 继续传播，

请你用IDE。 拼写错误直接提示。 你写都写不出来。

最后再强调一次： 把IDE和VIM/EMACS都深刻体会完以后，你再来发表看法

--

---
您收到此邮件是因为您订阅了Google网上论坛中的“TopLanguage”论坛。
要取消订阅此论坛，并停止接收其发来的电子邮件，请发送电子邮件至pongba+un...@googlegroups.com。
如需了解更多选项，请访问https://groups.google.com/d/optout。

[Xinyu LIU]

“聪明”的ide直接把希腊字母iota标记为拼写错误，然后建议你换成库函数itoa...

我并非想说IDE不如Emacs/VIM，我想说的是我们不能依赖工具来代替记忆和思考。

如果非要做一个投票，我只投票给白纸+铅笔。

分享一个Dijsktra老先生的手稿：

https://www.cs.utexas.edu/users/EWD/ewd09xx/EWD934.PDF

鄙人从Turbo Vision开始，到Visual C++ 6 + tomato assistant年代只用IDE，后来有了版权意识开始用vim，2004年后，工作中用eclipse，在2007年开始用Emacs。

现在我隔三差五到公司的打印机收集废纸。真是一条顽固不化的反动路线 ：）

Larry, LIU Xinyu
https://sites.google.com/site/algoxy/
https://github.com/liuxinyu95/AlgoXY

[Kroderia]

我觉得写itoa的频次以及把itoa写成iota的频率比iota和iota写成itoa要高得多。IDE要解决的是大部分问题，不是解决所有问题

Sent from my iPhone

[qiaojie]

你的说法我不认同，我认为只有用工具帮助记忆，然后我们才能多一点时间来思考。

白纸和铅笔的输入太慢，缺乏过滤和搜索功能，效率太低了。

[faen zhang]

同意qiaojie的说法。

否则， 干脆用树枝在地上划，用纸和笔还是不够高大上

[ken.cc]

[Final] 21月体验反馈并[分享]剑桥大学相关文章

今天看到 剑桥大学一篇相关的实验报告，正好把这个话题收尾了。

文章链接：

https://www.cl.cam.ac.uk/~as2006/files/sarkar_2015_syntax_colouring.pdf

并附上 reddit 上的讨论：

https://www.reddit.com/r/programming/comments/3ubdtj/the_impact_of_syntax_colouring_on_program/

有兴趣的同学最好看一下原文，下面的总结肯定不完整，并且会有错误。

这篇文章大概情况，

背景：

之前的研究基本都是基于自然语言，但自然语言的关键词设定并不通用，

但是编程语言的关键词却是 已被规定的，即统一通用的，所以更具研究价值。

（程序代码的排版也是结构化的。）

实验体：10人，

目标：

语法高亮能否影响 阅读（理解）程序代码的速度，并且是否与编程经验相关。

方法：

1. 程序代码理解。

对比高亮和非高亮时，实验人员手动运算代码 的速度。

2. 使用“眼动跟踪仪”（eye tracker）收集视线数据，

3. 前人的测试模型用于矫正数据。

结论：

语法高亮“极大程度的”提高了实验任务的完成效率，

编程经验越 丰富 此效果越 低。

The presence of syntax highlighting significantly reduces context switches.

...

In some cases, ...able to ignore highlighted keywords entirely,

...

讨论：

[见原文]

--------------------------

我自己21个月以来的体验反馈

结论：

语法高亮，加速 视觉疲劳，影响视力。

语法高亮 _一定程度_影响代码阅读，_确实_影响工作效率。

对我碰到的情况各举一例：

1. 影响代码阅读举例

面试过程中，一段python 代码，本来应该是，

for i in list:

...

被写成，

if i in list:

...

被面试者花了好长时间才发现问题。

这是之前说到的，依赖语法高亮，导致选择性忽略关键词。

当然这也许跟人处在 压力 情况下有关。

2. 高亮加速疲劳举例

我的终端模拟器的配色是 默认的黑底灰字（grey on black），

不用编辑器语法高亮很久，

那天比较累，

晚上10点左右，

看了一眼tmux 右下角的时间，绿底黑字，眼睛就像针扎一样。

( tmux 默认的绿底黑字参考图片：

http://www.68idc.cn/help/uploads/allimg/150112/1T6015R4_1.png )

然后我开了语法高亮，看一个c 文件，同样的绿色，同样的“亮瞎眼”。

这个时候的注意力明显会集中在闪亮的关键词上，而不是逻辑。

3. 超长、复杂的api 命名问题

自动补全 可以解决，甚至有 支持模糊搜索的自动补全。

不是语法高亮的问题。

4. 不考虑疲劳度，非高亮是否降低效率

我没法给出确切答案，因为这21个月间，写代码并不多，也不好掐着表，

衡量效率变化……

过了适应期，其实也没发现效率降低的问题。

唯一纠结的是像 lisp 这种，括号嵌套多了的时候，心里没有安全感，

但是 括号的配对高亮 或 配对移动 也能满足需求了。

5. 其他

Larry, LIU Xinyu 的观点全是实实在在的经验之谈，两年之后再看，我只能更加赞同了。