反对语法高亮的情况

在开发软件的时候,你依赖语法高亮吗?如果是,那么你或许正搬起石头砸自己的脚。本文,我将讨论审美上诱人的语法高亮,把关注点从内容迁移到了形式,阻碍阅读代码的人尽量去理解代码。

[caption id=”attachment_1328” align=”alignnone” width=”482”]一个语法高亮的例子 一个语法高亮的例子[/caption]

背景

语法高亮是大部分现代文本编辑器和开发环境的标准特性。基本思路是在多种语法元素之间增加视觉上的区别,降低程序员区分关键词、标点符号和变量名称之间的难度。

为什么语法高亮首先被发明了呢?在程序员阅读代码、思考“)”可能是一个变量名或者预处理器指令的时候,会混淆语法吗?当然不会。阅读计算机程序常常不那么容易,难度来自于程序的错综复杂,而非语法。

易读性

或许发明语法高亮是为了加快阅读速度。是的,一定是这样的,高亮的代码必须更容易阅读。毕竟,它是彩色的!

哦哦,不是。排版中的翻阅有个基本规则,当阅读一段文字时,你应该选择一种字体并持续下去。同样,一点点的颜色可能抓住了读者的注意力,不过它将不可避免地降低文本的易读性。文本的自然流被破坏了,需要花费更多的脑力把个别的字母组成单词和语义。从认知上看,阅读过程稍微少了些不假思索,稍微多了些注意;用来实际理解文本的、有意识的部分,少了一些空间。

[caption...

你不能比较语言特性,只能比较语言

很多编程语言的争论方式是“X特性真的不错,每种语言都需要它”,或“X特性比与之相对的Y特性要好很多”。经典例子是 静态 VS 动态类型,不过还有很多例子,比如元编程的不同类型等。

我经常发现自己被扯在这些辩论中的不同方向,因为我对Haskell和Python稍微有些不公平了。但是我想提议的是,做这种抽象的比较、而没有基于具体的语言,是一种误导,原因如下:

就我的经验看,Haskell里的静态类型与C的静态类型几乎完全不同,与C#1.0就更不同了,据我所知,与C#5.0的静态类型更加不一样。把这些静态类型混在一起真的有意义吗?

类似地,Shell脚本、PHP、Python和Lisp里的动态类型或许比它们本来的样子更加不同。你甚至不能把它们放在一个范围内——例如,与PHP相比,Python不是简单的‘强’类型系统(不能把字符串转换成数字等),因为它也有支撑更大灵活性和威力(比如基于第一类对象的动态子集)的特性。

特性组合是无关紧要的至关紧要的

比如,我最喜欢的Python特性之一是关键字参数。它们经常增加调用代码的清晰度,以向后兼容方式给函数增加新特性的功能。然而,这些特性只有在和其它特性组合时才有意义。如果你有关键字参数、而没有传递或接受关键字参数未知集合的**kwargs语法,那么这将让decorator变得非常难。

如果你正在思考Python有多么优秀,那么我不认为它对你把总的关键字参数做为杀手级特性去谈论有多少帮助。它是在Python里运行尤其良好的关键字参数。

比较语言特性给不好的争论带来了很多机会

例如:

攻击最糟糕的实现

动态类型支持者可能说,静态类型意味着相对于指示类型(indicate type)太过重复和冗长呆板。这种批评可能应用到Java,但是它不好应用到Haskell和很多其它的现代语言,在你可能需要定义类型的地方,类型推理(type inference)处理了95%的情况。

追踪进度,向高手学习

2008年夏天,我的工作地点位于Seeley W. Mudd大楼地下室里的哥伦比亚大学等离子物理实验室所,我们的实验在一个从来没有使用过的Mark III TRIGA核试验反应堆的钢筋混凝土外壳裹着的大型不锈钢真空管里。与实验相关的器材有低温泵、高压线、射频发生器和数以百计的诊断传感器,我们当时在研究偶极磁场中的氢等离子体,比如地球表面的和产生极光的氢等离子体。

这是我第一次经历正式的研究工作,那时候我还是应用物理系的一名学生。在我们组有个优秀的家伙,他看起来真正地有条理。与 和我在一起共事的其他科学家 相比,他更有效率。对于他在做什么,他总是有着清晰的思路,在他追踪进度时,总是一丝不苟地做笔记。

和高手在一起

追赶精英

我学到的一个心得就是,如果你想提高自己的效率,你就需要和精英们在一起。如果你想成为更好的学生、学者、科学家、企业家或任何角色,就和你能找到的最优秀的人相处在一起。

我对这个家伙最深的印象是他使用 做研究用的笔记本 如何高效地追踪其工作。都是数字,一天一篇文档。在写下所有想法时,他在顶部写上日期,然后只是在文档里拖放一些数字、表格、数据和公式。这是我曾经见过的最不寻常的事情。

...