排队运营商是一种有价值的风格吗？答案

【问题标题】：Is lining up operators a worthy style?排队运营商是一种有价值的风格吗？
【发布时间】：2008-11-12 22:42:14
【问题描述】：

some_var = foo()
another_var = bar()

或

some_var    = foo()
another_var = bar()

包括在添加或删除行时更改空格以保持它们对齐。这真的好看吗？是否值得搞砸差异？

【问题讨论】：

你是如何制作差异的？告诉它忽略空格的变化。

标签： coding-style

【解决方案1】：

我不认为这是一种好的风格，因为它很难进行更改（您必须重新进行所有工作来重新排列它们），而且对我来说，没有额外的空格它是完全可读的。

对此特别烦人的是，当您更改比所有其他行都长的行的左侧部分时，您需要重新排列所有其他行。

例子：

some_var    = foo()
another_var = bar()

现在我想添加一个名为another_another_var的变量：

some_var    = foo()
another_var = bar()
another_another_var = baz()

现在我必须重新排列它们：

some_var            = foo()
another_var         = bar()
another_another_var = baz()

很烦人。

【讨论】：

【解决方案2】：

从我作为 VCS 管理员的那段时间开始，几乎没有文体问题值得解决差异。我们有一个开发者通过他的变性程序改名，而她的新名字没有相同的首字母。然后，每当她在一个程序上工作时，她都会将她以前的首字母缩写为新的，这让我很烦恼。

【讨论】：

这样的情况应该分成两个变化，这样“绒毛”可以被隔离，不太可能隐藏重要的变化。不过，很难记住这样做。
是的，这很烦人，但如果我必须在变性和因为改名而忍受 2000 个差异之间做出选择，我绝对知道我更喜欢什么。希望她对自己的新生活感到满意。

【解决方案3】：

使用 Perl，您可以设置您的偏好并时不时地对您的代码运行 perl-tidy。

它在正确的上下文中提供了对齐 = 的优点，无需担心如何最好地对齐它们并记住自己做。

此外，无论您在项目中使用了何种编码风格，都应该积极维护它。

风格越一致且执行得越严格，就越容易发现代码中的怪异之处和编程错误。

此外，对编码风格的一些强制措施通过强制执行良好的换行规则长期减少基于差异冲突的问题。

【讨论】：

【解决方案4】：

不可以，除非变量之间存在某种垂直关系，例如：

some_var[  1] = "foo";
some_var[100] = "bar";

但我这样做的情况很少见，尤其是当我只有几个变量时。这在 SQL 中比较常见，我可能在一行中包含参数名称、类型和默认值（三部分），但即使在那里我也尽量避免它——这不值得麻烦。

@some_var varchar(25) = NULL
@another_var varchar(1000) = ''
@one_more int = 0

【讨论】：

【解决方案5】：

没有。

虽然有些人觉得这种风格很讨人喜欢，但带有语法突出显示的现代 IDE 会以这种方式对齐变量浪费时间，包括在重构或修改代码时重新格式化它们所花费的时间。

此外，我坚信将变量声明为接近需要它们的范围。这很少会导致甚至需要对齐的变量声明块。

【讨论】：

【解决方案6】：

这样的样式会导致眼睛垂直移动；但是，代码应该是水平阅读的。编码风格应该与眼睛的功能相辅相成，而不是与之抗衡。

【讨论】：

【解决方案7】：

此外，在极端情况下，由于差距很大，很难随便看出哪个作业去哪里了。这是我在头文件中经常看到的。

...
some_important_number                                             = 348273;
initial_message_prefix                                            = "foo";
another_important_number                                          = 348711;
max_bucket_sz                                                     = 456;
...

一个块中有几十个，很难阅读。

【讨论】：

我希望你在夸大其词......：P
很遗憾，没有。这个例子是虚构的，但它来自真实的经验