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

851 views
Skip to first unread message

Ken CC

unread,
Feb 14, 2014, 9:17:47 AM2/14/14
to pon...@googlegroups.com

最近折腾编辑器的时候,看到一篇文章:
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

unread,
Feb 14, 2014, 9:36:18 AM2/14/14
to TopLanguage]列表
无法同意更多
> --
>
> ---
> 您收到此邮件是因为您订阅了 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

unread,
Feb 14, 2014, 9:39:40 AM2/14/14
to pon...@googlegroups.com
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
syntax2.png

Doyle

unread,
Feb 14, 2014, 9:48:31 AM2/14/14
to pongba

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

Zhang Xiang

unread,
Feb 14, 2014, 10:14:33 AM2/14/14
to TopLanguage
不同意,还是有语法高亮比较好


--

Xpol Wan

unread,
Feb 14, 2014, 10:22:21 AM2/14/14
to pon...@googlegroups.com
语法高亮对代码的debug 并没有多大的帮助:

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

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

Best Regards!

Xpol Wan
// There is a better way!

Xpol Wan

unread,
Feb 14, 2014, 10:24:10 AM2/14/14
to pon...@googlegroups.com
PS,楼主,情人节、元宵节不去过。在这里谈技术,简直就是“双节棍”啊。

Best Regards!

Xpol Wan
// There is a better way!


Xiong Zhou

unread,
Feb 14, 2014, 10:28:41 AM2/14/14
to pon...@googlegroups.com

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

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

iridium

unread,
Feb 14, 2014, 11:44:29 AM2/14/14
to pon...@googlegroups.com
 是的。

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

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

unread,
Feb 14, 2014, 12:02:55 PM2/14/14
to pon...@googlegroups.com
“1. 多种颜色会分散读者的注意力”

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

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

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

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

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

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

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

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

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

Jawley

Forwarded message:

Ken CC

unread,
Feb 14, 2014, 9:23:22 PM2/14/14
to pon...@googlegroups.com
On Fri, Feb 14, 2014 at 11:14:33PM +0800, Zhang Xiang wrote:
> 不同意,还是有语法高亮比较好
>

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

:-)


-ken

Ken CC

unread,
Feb 14, 2014, 9:31:28 PM2/14/14
to pon...@googlegroups.com
On Fri, Feb 14, 2014 at 11:22:21PM +0800, Xpol Wan wrote:
> > 语法高亮对代码的debug 并没有多大的帮助:
>
> 高亮是提高阅读的便利吧。不是用来debug的。
>

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

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


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


-ken

Ken CC

unread,
Feb 14, 2014, 10:07:56 PM2/14/14
to pon...@googlegroups.com
On Fri, Feb 14, 2014 at 11:28:41PM +0800, Xiong Zhou wrote:
> 针对代码来谈快速阅读能力有些不妥,纯文本和代码不是一回事。
>

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

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

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


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

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

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

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

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

哈哈,我一点也不偏激。


-ken

Zoom.Quiet

unread,
Feb 14, 2014, 10:22:34 PM2/14/14
to TopLanguage]列表

点赞!
实践出真知!

Zoom.Quiet from N7108

Zhang Xiang

unread,
Feb 14, 2014, 10:53:37 PM2/14/14
to TopLanguage
你拿记事本打开一个源代码看看感觉一下吧。


Mi Vman

unread,
Feb 14, 2014, 11:18:05 PM2/14/14
to pon...@googlegroups.com
个人习惯问题。
如果代码结构清晰,高亮不高亮影响不大。
眼睛舒服了,脑子也轻松。
---------------------------------------------
在 2014年2月14日星期五UTC+8下午10时17分47秒,ken.cc写道:

Ken CC

unread,
Feb 14, 2014, 11:32:12 PM2/14/14
to pon...@googlegroups.com
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

unread,
Feb 14, 2014, 11:38:45 PM2/14/14
to pon...@googlegroups.com
On Sat, Feb 15, 2014 at 11:53:37AM +0800, Zhang Xiang wrote:
> 你拿记事本打开一个源代码看看感觉一下吧。
>

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

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


-ken

Bowen Ma

unread,
Feb 15, 2014, 3:49:03 AM2/15/14
to pon...@googlegroups.com
不会干扰到,还有些许帮助吧


-- 
Bowen Ma
Sent with Sparrow

lor fal

unread,
Feb 15, 2014, 10:29:47 PM2/15/14
to pon...@googlegroups.com
在阅读legacy code的时候没有语法高亮怎么活啊~
语法高亮可以在视觉上对代码块进行分块处理,一眼看过去更清晰,更容易定位。
--
Best regards,
LORFAL

郎咸武

unread,
Mar 7, 2014, 5:39:23 AM3/7/14
to pon...@googlegroups.com
从看到此帖开始把vim的高亮去掉了,到现在已完全适应黑和白,加上高亮后感觉有点晃眼。从此不在担心远程连接服务器没有高亮显示的情况了。


--

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



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

Luo, Carrot

unread,
Mar 7, 2014, 5:42:02 AM3/7/14
to pon...@googlegroups.com
合适就好,晃不晃眼无非是颜色方案的问题。 高亮本身就是为了让眼睛聚焦真正重要的东西,如果没有高亮,眼睛会很痛苦,工作时间也就成问题了,头晕眼酸神马的


--

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

郎咸武

unread,
Mar 7, 2014, 5:53:04 AM3/7/14
to pon...@googlegroups.com
从另一角度考虑,这应该是有意识行为和无意识。虽然代码高亮显示没有了,但在文件中查找某个关键字时,高亮显示查找的关键字还是非常有用的。
--
只为成功找方法,不为失败找理由

Leo

unread,
Mar 7, 2014, 3:33:31 PM3/7/14
to pon...@googlegroups.com
谁知道emacs gdb模式下,如何高亮显示gdb的输出,尤其是bt和info threads

qihang zhang

unread,
Mar 10, 2014, 1:27:18 AM3/10/14
to pon...@googlegroups.com
怎么看大家的回复就好像不用语法高亮的是主流?!
大家平常真的不用语法高亮么?!
反正我是对这篇文章(lz分享的)一点也不感冒,我不但要用高亮,还要用好看的,养眼的高亮,一个看烦了还要换另一个 :)
给同好者推荐https://github.com/chriskempson/tomorrow-theme ,最近在用,很不错 :)


--

月忧茗

unread,
Mar 10, 2014, 8:55:31 AM3/10/14
to pon...@googlegroups.com
别人我不清楚, 反正我离不开语法高亮。

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

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

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

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

Yongwei Wu

unread,
Mar 10, 2014, 10:12:40 AM3/10/14
to pon...@googlegroups.com
顶上。有IDE用IDE,没有IDE或者偶尔IDE不给力时用Vim。没有Vim,Notepad上也没什么大不了。但千万别跟我说Notepad是最好的工具!
Wu Yongwei
URL: http://wyw.dcweb.cn/

faen zhang

unread,
Mar 10, 2014, 1:42:48 PM3/10/14
to pon...@googlegroups.com
能不能做个投票?
我个人喜欢代码高亮, 可以帮我快速的定位信息和快速的过滤信息

Yuuki Galaxy

unread,
Mar 11, 2014, 5:37:13 AM3/11/14
to pon...@googlegroups.com
最简单的例子,在字体不好区分的情况下,两个单引号,一个英语双引号,一个中文双引号,就得靠语法高亮区分。

CPluser

unread,
Mar 11, 2014, 10:12:31 AM3/11/14
to pon...@googlegroups.com

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

Xinyu LIU

unread,
Mar 11, 2014, 11:44:57 PM3/11/14
to pon...@googlegroups.com
说个亲身体会。有一阵,我在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纸背面和铅笔。

robin...@gmail.com

unread,
Mar 12, 2014, 12:11:54 AM3/12/14
to pon...@googlegroups.com
Hi all,

看了这么多讨论,有一个疑问:

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

发自 Windows 邮件

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

houzhanfeng

unread,
Mar 12, 2014, 12:23:29 AM3/12/14
to pon...@googlegroups.com

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

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

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

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


 原始邮件 
发件人: Xinyu LIU<liuxi...@gmail.com>
发送时间: 2014年3月12日(周三) 11:44
主题: Re: [TL] Re: [OT] 语法高亮会干扰代码阅读吗?

qiaojie

unread,
Mar 12, 2014, 12:44:32 AM3/12/14
to pon...@googlegroups.com
用auto complete可以减少我们的记忆量,但不是什么坏事,也无关效率。记不记得一个API的名字对编程来说无关紧要,重要的是API背后的功能和设计,过分拘泥于细枝末节反倒不利于思考。

郎咸武

unread,
Mar 12, 2014, 12:50:55 AM3/12/14
to pon...@googlegroups.com
个人觉得常用的API名字都记不住的话,确实不怎么好。 如果有人在群里或户外聚会或.....讨论时。就是想不起API名字交流肯定受影响。有次我就想不起来反编译Erlang代码的参数。最后只能手机查阅了一下。
只为成功找方法,不为失败找理由

Frank Ren

unread,
Mar 12, 2014, 12:53:50 AM3/12/14
to pon...@googlegroups.com
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

葛光乐

unread,
Mar 12, 2014, 12:54:05 AM3/12/14
to pon...@googlegroups.com
怎么单独屏蔽这个话题

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

jyf

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

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

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

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

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

葛光乐

unread,
Mar 12, 2014, 1:03:49 AM3/12/14
to pon...@googlegroups.com
怎么单独屏蔽这个话题

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


--

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

Xinyu LIU

unread,
Mar 12, 2014, 1:15:32 AM3/12/14
to pon...@googlegroups.com
gmail的话,你可以用m来mute这个thread。

月忧茗

unread,
Mar 12, 2014, 1:17:09 AM3/12/14
to pon...@googlegroups.com
上面说的 emacs 自动补全 导致前面的拼写错误 继续传播,

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

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


--

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

Xinyu LIU

unread,
Mar 12, 2014, 1:53:13 AM3/12/14
to pon...@googlegroups.com
“聪明”的ide直接把希腊字母iota标记为拼写错误,然后建议你换成库函数itoa...

我并非想说IDE不如Emacs/VIM,我想说的是我们不能依赖工具来代替记忆和思考。
如果非要做一个投票,我只投票给白纸+铅笔。

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

鄙人从Turbo Vision开始,到Visual C++ 6 + tomato assistant年代只用IDE,后来有了版权意识开始用vim,2004年后,工作中用eclipse,在2007年开始用Emacs。
现在我隔三差五到公司的打印机收集废纸。真是一条顽固不化的反动路线 :)

Kroderia

unread,
Mar 12, 2014, 2:18:31 AM3/12/14
to pon...@googlegroups.com
我觉得写itoa的频次以及把itoa写成iota的频率比iota和iota写成itoa要高得多。IDE要解决的是大部分问题,不是解决所有问题

Sent from my iPhone

qiaojie

unread,
Mar 12, 2014, 2:24:40 AM3/12/14
to pon...@googlegroups.com
你的说法我不认同,我认为只有用工具帮助记忆,然后我们才能多一点时间来思考。
白纸和铅笔的输入太慢,缺乏过滤和搜索功能,效率太低了。

faen zhang

unread,
Mar 12, 2014, 2:32:54 AM3/12/14
to pon...@googlegroups.com
同意qiaojie的说法。
否则, 干脆用树枝在地上划,用纸和笔还是不够高大上
Message has been deleted

ken.cc

unread,
Nov 27, 2015, 12:34:45 AM11/27/15
to TopLanguage

[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 的观点全是实实在在的经验之谈,两年之后再看,我只能更加赞同了。

Reply all
Reply to author
Forward
0 new messages