这是一个非常主观的话题，但您可以从 1000 年的印刷历史中获得一些线索。
已经对排版中的空白进行了研究，但对代码的研究较少。但是您可以假设在易读性和理解性方面的许多基本发现也适用于代码。这项名为“阅读在线文本：四种空白布局的比较”的研究表明，具有较大边距的适当垂直间距可以提高理解力，但会减慢速度。对于代码，可以安全地假设理解比速度更重要。所以你可以客观地说，更多的空间更适合代码。但是，当您了解标签大小和支撑位置的细节时，它会变得非常主观。在代码中，边距是缩进，段落是函数和代码块，句点是换行符、大括号、括号等。
但是，当您开始询问程序员哪种格式的空白更易读时，答案是全范围的。你能做的最好的事情就是寻找似乎普遍的普遍性。
如：
- 在代码块之前和之后放置空格，例如函数和类
- 在块内代码的逻辑分组之前和之后放置空格
- 没有垂直空格的长代码块更难阅读
- 没有缩进的长代码块更难阅读
- 没有水平空格的长代码行更难阅读
我想大多数程序员都会同意这些说法。
示例（伪代码）：
thisismore(difficult<toread)because,itsall-smushed{together}
this-is-less ( difficult < to-read ) because, it's-not-all - smushed { together }
谈到你的最后四点：
变量命名：
这与空白一样主观，但您可以再次从排版中寻找线索。排版有衬线字体、大写字母开头的句子、句点结尾的句子和句点后的空格。所有这些都是为了让你的眼睛在单词和句子之间转换。对于变量，清晰度很重要，因此它们通常是多词名称。为了让您的眼睛轻松阅读它们，需要有一些东西提醒他们一个新单词已经开始。
这更难阅读（对于大多数人来说）：
比这些：
- 我的长变量名
- 我的长变量名
- my_long_variable_name
- MY_LONG_VARIABLE_NAME
现在，哪些是最好的或最易读的是主观的，并且可能总是如此。但重要的是有一些东西可以将这些词分开。
水平缩进：
完全不缩进的代码比缩进的代码更难阅读。压痕太小，您的眼睛难以区分块。太大，你会浪费空间，也不会增加清晰度。根据使用这些大小编写的 110 亿行代码，四到八之间似乎是正确的。
水平对齐：
再次，排版的救援。在列中对齐的事物列表更易于阅读。对于超过一个或两个单词或数字（如句子）的列表项数据，使用项目符号列表。对于文本数据，使用左对齐的列。对于数值数据，使用右对齐列。您可以将这些原则应用于代码。项目符号列表可以看作是代码块，都与相同的缩进级别对齐。变量是文本数据，所以左对齐最容易阅读。如果您分配的值是数字，则最好右对齐。
这更难阅读（对于大多数人来说）：
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;
垂直间距：
想象一下整篇文章，段落之间没有空格。几乎每个人都同意这将更难阅读和理解。现在，许多人可能会争辩说，部分之间的更多空间会更好。在排版中，部分由具有更大字体大小和更多垂直空间的标题来描述（就像您在 HTML 中看到的 H1 等一样）。在代码中，我们有一个字体大小，所以我们必须使用空格和语言使用的任何支撑概念（如果有的话）。像水平间距一样，多总比少好。关于这意味着什么的具体细节是主观的，但是对于大多数语言，程序员都会接受大多数人使用的那种语言的约定。如果您要定义自己的语言（或编码标准），则可以设置约定。
最重要的是，无论标准是什么，它在您的所有代码中始终如一地使用。这比标准的细节更重要。无论标准是什么，一致格式化的代码都容易得多。
搜索排版可读性研究以获取更多信息。