Question

对于手动换行长线，您选择破线的个人启发式是什么？

假设这条线太长，你可能在哪里打破它，它的优先顺序是什么？

double var = GetContext()->CalculateValue(element, 10.0);

大多数人都同意每行分离参数：

double var = GetContext()->CalculateValue(element,
                                          10.0);

有没有人在开幕式上打破？

double var = GetContext()->CalculateValue(
                                 element, 10.0);

但是如何解除引用运算符（或.）：

double var = GetContext()
                 ->CalculateValue(element, 10.0);

或者你会：

double var = GetContext()->
                 CalculateValue(element, 10.0);

赋值运算符有什么不同吗？

double var = 
    GetContext()->CalculateValue(element, 10.0);

或

double var
    = GetContext()->CalculateValue(element, 10.0);

还有其他人吗？

如果您的系统是程序性的，您可以这样回答：

或者只是发布一些示例代码！
如果你能在学术上证明你的决定是正确的，那么奖励积分。

Answer 1

我喜欢使用绑定顺序进行拆分，最先接近行尾。所以在你的例子中我会分开=符号。如果这仍然溢出边缘，我会分开 - ＆gt;

分割线的想法完全是为了读者的利益（因为编译可能不在乎）。我发现从心理上来说，精神上很容易将代码分成逻辑组。

Answer 2

在你的具体例子中，我个人会选择第四个：

double var = GetContext()->
             CalculateValue(element, 10.0);

我从不喜欢严格定义的代码格式标准，除了总是格式化一个代码的基本规则，以便它有意义（特别是对没有写它的人）并且易于阅读。任何过于宽泛的规则，例如“总是在这个或那个地方放置一个换行符”，甚至“总是用这个或那个命名方案命名变量”只是不适合我。从长远来看，我发现它弊大于利。

它没有很好地解释边缘情况，它把重点放在错误的东西上（语法点而不是代码的实际可读含义和流程）并且它进一步促进了商品化开发人员的目标在不考虑开发人员自己的最佳判断的情况下尽可能即插即用的位置。

（好吧，这可能已经变成了一种咆哮。我道歉。但重点仍然存在。）

基本上，在没有任何具体规则的情况下，应该根据具体情况，以可读的方式使代码最佳地适合它。开发人员应该相应地使用他们的最佳判断。

Answer 3

我在现场拆分并缩进到使代码最具可读性所需的级别。这是所有的美学，所以任何“学术上的理由”都不会比任何其他人为的，后推理的借口更有用，无论你做出任意决定开始做什么。

Answer 4

我喜欢打开括号然后在每个参数

Answer 5

对于这一行：

double var = GetContext()->CalculateValue(element, 10.0, foo);

我会在第一个参数之后断开链接，然后将第一个参数开始的后续元素排成一行，但是在下一行：

double var = GetContext()->CalculateValue(element,  
                                          10.0, foo);

如果第二行太长，请制作第三行，依此类推。