[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 邮件

发件人: Xinyu LIU
发送时间: ‎2014‎年‎3‎月‎12‎日, ‎星期三 ‎11‎:‎44
收件人: pon...@googlegroups.com

[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背后的功能和设计，过分拘泥于细枝末节反倒不利于思考。