使用空白来对齐代码是否被认为是一种好的样式?[关闭]

Python's PEP 8 (这是“Python代码的样式指南”)要求您不要使用空格来对齐代码:

宠物的烦恼

Avoid extraneous whitespace in the following situations:

…

- More than one space around an assignment (or other) operator to
  align it with another.

  Yes:

      x = 1
      y = 2
      long_variable = 3

  No:

      x             = 1
      y             = 2
      long_variable = 3

你换标签了吗?我看到几个关于python的答案,但是我看到的唯一语言标签是scala。如果你对斯卡拉感兴趣,我可以参考非官方的 Scala Style Guide . 根据样式指南,我建议您的示例如下所示:

val foo = -1
val bar = 1
val yohoho = Double.NaN

这只是我的拙见,但我个人讨厌缩进,就像 任何 程序设计语言。有人说“看起来不错”,但我觉得完全不切实际。例如,为了重命名变量 yohoho 您必须重新排列周围的所有其他变量(大多数编辑器不会帮助您实现这一点)。

当使用重构工具重命名变量时,第二种样式将变得混乱。

无论什么适合你,你都是编码员。第一个看起来真的很有趣。

scala不会强迫你以任何一种方式工作,但是第一种方式通常是首选的,因为如果你必须添加一个新行,然后重新处理其他所有的东西,它确实会破坏不同的工具。

另一方面,如果代码/算法在对齐时可读性更高,那么请将其对齐!根据敏捷宣言,可读性胜过所有其他关注点:

• 过程和工具上的个人和交互

也就是说,让其他程序员开心比让不同的工具开心更重要。

我在Python中尝试过这种方法,例如在Django模型声明中。

当您稍后修改代码时,它会变成一种OCD引起的疼痛。例如,如果在第二个示例中添加一个名为yoohoohoey的var,会怎么样?您必须返回并在每行中添加空格,使其与新的长度对齐。

所以,我更喜欢第一种方式。

如果必要的话,我用第二种方法。这样做很费时,但只要花点时间,您就可以配置自动格式化使其自动进行。

但这是一个偏好问题。

这个 Scala Style Guide 对主题保持沉默,但我在scala代码中没有看到垂直对齐声明,所以我将选择第一个选项。

如果你的目标是遵守社区指南,那么第一个可能更常见。但是,您是想适应——还是想突出代码的质量?学习什么对你有用是非常重要的。

我建议你尝试两种风格——然后看看你如何发现两者都能工作。对我来说,对齐变量是一件痛苦的事情,但是在处理较大的代码文件时,它非常有用。当我陷入代码的某个特定方面,并且希望有一点时间让我的想法渗透进来时,这也是一项很好的忙碌工作。

沿着这一思路,我发现,当使用例如javascript时,将函数的第一行推到最左边时,可以非常快速地扫描代码。这打破了正常的缩进规则——但它帮助我更好地阅读代码,而不是很好地缩进代码。

任何适合你的东西,只要你自己工作就够了。如果你是一组开发人员的一部分,你应该投票并坚持一种方式。保留一个编码标准列表,并在代码检查中加以实施。

一个scala文件中有多个初始化的val或var声明的频率是多少?如果可能的话,类中的顶级VAL和var应该主要是主构造函数参数。特性中的顶级VAL可能是抽象的,因此不会初始化。方法中的vals和var绝对不应该被填充,因为重新排序的可能性太大。

我刚刚搜索了一个200类的scala项目,只找到了一个甚至出现这个问题的类(一个“蛋糕模式”模块,其中vals声明了我的应用程序的组件)。这不是问题。

无论什么适合你,你都是编码员。第二个看起来真的很有趣。

无论什么适合你,你都是编码员。我发现第二个更难编辑。

我不能说Python,但一般来说,您可以在所有不同语言中找到这两个示例。根据我的经验,第一个例子更常见,但这是个人品味的问题,我不认为其他开发人员会认为你使用这两种风格都不好。

我非常喜欢第一个示例,并同意对第二个示例的可维护性进行了评论的其他人。现在所有的IDE和大多数高质量的文本编辑器都提供了突出显示语法的功能,我认为后一种样式对于保持内容的可读性是不必要的。

从阅读时的可用性角度来看,第二个类似于表格布局,它可以帮助您垂直扫描,以快速看到有两个整数和一个双整数,但是连接水平极端来查看条形图是1也有点困难。

第一个选项使单个行获得焦点,并且更容易水平扫描以查看条为1,但很难快速看到有两个整数和一个双整数。

用更多的行来扩展示例,可能更容易“感觉”到这一点,但要使用哪一个更重要,当然,在项目、团队、工作场所或所讨论语言的最佳实践中使用的是什么样式。

此外,为什么只将表布局限制为左对齐的列?^ ^

   val foo : Int    = -1
   val bar : Int    =  1
val yohoho : Double =  NaN

第二种风格,当你需要搜索特定的文本时会头疼。当代码文件变大时,有时需要查找特定的文本,如果使用自定义空间编码,则很难找到。
我们在保存TSQL脚本的大型XML文件、在我之前使用Style2的编码人员(如您的示例中所示)方面有过糟糕的经验,每当我们添加新规则或升级旧规则时,都会很难通过使用自定义空间编码的文件进行搜索。

这种缩进在有人读取代码时很有用,但这完全由您决定。 我的答案是不要使用它,你会节省一些时间,而且你真的想使用它,做一些文本编辑器来做它,或者自己做一些编译器来解释打印的HTML代码,因为在一个文本文件上做它是毫无价值的,我会提醒你,这是一个简单的长行字节,用制表符、空格和回车框重新组织。