Question

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

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

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

“没关系（没有理由提出索赔）”
“做社区已经为语言X推荐的内容。”

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

为这个问题提供“更加软弱”的动机：人们在阅读文档和艺术（如听音乐）时欣赏代码中的空白区域。这些领域都非常强调空间的重要性。

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

总之，如果可以，请触摸以下一项或多项：

变量命名约定
横向缩进
水平对齐（在多条线上对齐等号？）
垂直间距

Answer 1

有一个名为International Conference on Program Comprehension (ICPC)的年度IEEE会议，它经常有关于项目理解的实验研究。我在过去三年中发现的最相关的是：

An Eye Tracking Study on camelCase and under_score Identifier Styles“虽然结果表明两种风格之间的准确性没有差异，但主体会更快地识别下划线风格的标识符。”
To camelcase or under_score“结果表明，无论训练如何，骆驼套管都能在所有受试者中获得更高的准确度，而使用骆驼套管训练的人员能够比下划线中的标识符更快地识别骆驼案例中的标识符式“。

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

[Chaparro，2005]阅读布局不佳的在线文本：性能更差？作者：Barbara S. Chaparro，A。Dawn Shaikh，＆amp; J. Ryan Baker，“可用性新闻”，第7卷，第1期，2005年2月。
[Lin，2004]评估老年人在超文本阅读中的保留：Dyi-Yih Michael Lin在“人类行为中的计算机”第20卷第4期中对演示媒体的影响作为文本拓扑的函数2004年7月，第491-503页。可从ScienceDirect
Cognitive load in hypertext reading: A review。

这些论文没有直接解决这个问题，但我提到它们希望它们提供一些背景。感谢Michael Suodenjoki的博客文章White space matters in program source code。

，发现了前两个参考文献

Answer 2

这是一个非常主观的主题，但您可以从1000年的排版历史中获取一些线索。

已经对排版中的空白进行了研究，但对代码的研究则较少。但是你可以假设许多易读性和理解性的基本发现也适用于代码。这项研究Reading Online Text: A Comparison of Four White Space Layouts表明，适当的垂直间距和大边距可以增加理解力，但速度会降低。对于代码，可以安全地假设理解比速度更重要。所以你可以客观地说，更多的空间更适合代码。但是当你了解标签尺寸和支撑定位的细节时，它会变得非常主观。在代码中，边距是缩进，段落是函数和代码块，句点是换行符，括号，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中看到的那样）。在代码中，我们有一个字体大小，所以我们必须使用空格和语言使用的任何支撑概念（如果有的话）。像水平间距一样，越多越好。关于这究竟意味着什么的具体细节是主观的，但对于大多数语言，程序员都会适应大多数人使用的语言惯例。如果您要定义自己的语言（或编码标准），则可以设置约定。

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

搜索typography readability studies以获取更多信息。

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

2 个答案: