白色空间的实验研究成果(语言设计和风格指南)？

Question

实验研究对代码中的空白区域有何看法？让我具体一点:我所说的是认知研究,它可以比较人们阅读和掌握不同格式的视觉信息的速度和效果.

假设您正在设计一种新的计算机语言,并且必须做出一些影响源代码外观的决策.或者您只是为新语言编写风格指南,并希望提出建议.相关主题可能是标识符样式(snake_cased_identifiers与camelCaseIdentifiers/PascalCaseIdentifiers),水平缩进,文档样式或垂直间距.

我故意以这种方式提出这个问题,以避免以下建议:

• "没关系(没有理由提出索赔)"
• "做社区已经为语言X推荐的东西."

我不希望支持不同方法的人之间发生火焰战争; 相反,我想知道实验研究对此事有何评论.(我不认为任何特定的研究必须完全'客观'或'中立'.)

为这个问题提供一个"更加软弱"的动机:人们在阅读文档和艺术(如听音乐)时欣赏代码中的空白.这些领域都非常强调空间的重要性.

所以,谢谢,我很高兴听到这些研究的内容.要明确的是,我并不排除风格和艺术的重要性 - 我实际上希望这些世界的智慧能够在实验研究中出现.

总之,如果可以,请触摸以下一项或多项:

• 变量命名约定
• 水平压痕
• 水平对齐(将多条线上的等号对齐？)
• 垂直间距

Answer 1

每年一度的IEEE会议名为" 国际计划理解会议" (ICPC),该会议通常有关于计划理解的实验研究.我在过去三年中发现的最相关的是:

• 关于camelCase和under_score标识符样式的眼睛跟踪研究 "虽然结果表明两种样式之间的准确性没有差异,但是主体更快地识别下划线样式的标识符."

• 对于camelcase或under_score "结果表明,无论训练如何,骆驼套管都能在所有受试者中获得更高的准确度,而使用骆驼套管训练的人能够比下划线样式中的标识符更快地识别骆驼案例中的标识符."

除了计算机科学特定的认知文献,还有关于在线和超文本阅读的研究:

• [Chaparro,2005]阅读布局不佳的在线文本:性能更差？作者:Barbara S. Chaparro,A.Dawn Shaikh,和J. Ryan Baker,可用性新闻,第7卷,第1期,2005年2月.

• [Lin,2004]评估老年人在超文本阅读中的保留:Dyi-Yih Michael Lin在"计算机在人类行为",第20卷,第4期,2004年7月,第491页中对演示媒体的影响作为文本拓扑的函数503.可从ScienceDirect获得

• 超文本阅读中的认知负荷: Diana DeStefano和Jo-Anne LeFevre的评论.

这些文件没有直接解决这个问题,但我提到它们希望它们提供一些背景.前两个参考文献被发现感谢Michael Suodenjoki的博客文章" 程序源代码中的白色空间问题".

Answer 2

这是一个非常主观的话题,但你可以从1000年的排版历史中获得一些线索.

已经对排版中的空白进行了研究,但对代码的研究则较少.但是你可以假设许多易读性和理解性的基本发现也适用于代码.这项研究,阅读在线文本:四个白色空间布局的比较,表明适当的垂直间距和大边距增加了理解力,但速度减慢.对于代码,可以安全地假设理解比速度更重要.所以你可以客观地说,更多的空间更适合代码.但是当你了解标签尺寸和支撑定位的细节时,它会变得非常主观.在代码中,边距是缩进,段落是函数和代码块,句点是换行符,括号,parens等.

当你开始向程序员询问什么样的空白格式更具可读性时,答案就在各个方面.你能做的最好的事情就是寻找看似普遍的普遍性.

如:

• 在代码块之前和之后放置空格,比如函数和类
• 在块内的代码的逻辑分组之前和之后放置空格
• 没有垂直空格的长代码块更难以阅读
• 没有缩进的长代码块更难以阅读
• 没有水平空格的长行代码更难以阅读

我想大多数程序员都会同意这些陈述.

示例(伪代码):

thisismore(difficult<toread)because,itsall-smushed{together}
this-is-less ( difficult < to-read ) because, it's-not-all - smushed { together }

触及你的最后四点:

变量命名:

这与空白一样主观,但你也可以寻找排版的线索.排版具有衬线字体,大写字母起始句子,句点结束句子和句点后的空格.所有这些都是为了让你的眼睛在单词和句子之间转换.对于变量,清晰度很重要,因此它们通常是多字的名称.为了让你的眼睛能够轻松阅读它们,有些东西需要提醒他们一个新单词已经开始.

这对于大多数人来说更难阅读:

• mylongvariablename

比这些:

• 我长的变量名
• myLongVariableName
• my_long_variable_name
• MY_LONG_VARIABLE_NAME

现在哪一个是最好的或最具可读性的是主观的,并且可能总是如此.但重要的是将某些词分开.

水平缩进:

完全没有缩进的代码比代码更难阅读.压痕太小而你的眼睛难以区分块.太大,你浪费空间,不再增加清晰度.基于使用这些大小编写的十亿亿行代码,似乎是在4到8之间.

水平对齐:

再次,排版救援.列中对齐的事物列表更易于阅读.对于长于一个或两个单词或数字(如句子)的列表项数据,使用项目符号列表.对于文本数据,使用左对齐列.对于数字数据,使用右对齐列.您可以将这些主体应用于代码.项目符号列表可以看作代码块,所有代码块都对齐到相同的缩进级别.变量是文本数据,因此左对齐最容易阅读.如果您指定的值是数字,则右对齐将是最佳的.

这对于大多数人来说更难阅读:

var oneVariable = 10023, a = 370,
p = 4,
answerToLife = 42,
openThePodBayDoorHal = false;

比这个:

var oneVariable = 10023, 
    a = 370,
    p = 4,
    answerToLife = 42,
    openThePodBayDoorHal = false;

这可能是最简单的:

var oneVariable          = 10023, 
    a                    =   370,
    p                    =     4,
    answerToLife         =    42,
    openThePodBayDoorHal = false;

垂直间距:

想象一下整个帖子,段落之间没有间距.几乎每个人都同意这将更难阅读和理解.现在,许多人可能会争辩说各部门之间的空间会更好.在排版中,部分用标题来描绘,标题具有更大的字体大小和更多的垂直空间(就像你在带有H1的HTML中看到的那样).在代码中,我们有一个字体大小,所以我们必须使用空格和语言使用的任何支撑概念(如果有的话).像水平间距一样,越多越好.关于这究竟意味着什么的具体细节是主观的,但对于大多数语言,程序员都会适应大多数人使用的语言惯例.如果要定义自己的语言(或编码标准),则可以设置约定.

最重要的是,无论标准是什么,都是在所有代码中始终如一地使用它.这比标准的细节更重要.无论标准如何,一致格式化的代码都更容易.

搜索排版可读性研究以获取更多信息.