I like to make the splits in strength of binding order, closest to the end of the line first. So in your examples I would split at the = sign. If this still spilled over the margin I would split at the ->
The idea of splitting a line is solely for the benefit of readers (since the compile could care less). I find that mentally it is easier to mentally chunk pieces of code that are broken into logical groups.
double var = GetContext()->
CalculateValue(element, 10.0);
除了始终格式化代码以使其有意义的基本规则之外，我从来都不喜欢严格定义的代码格式化标准（特别是对于那些不这样做的人） t write it）并且易于阅读。任何过于宽泛的规则，比如“总是在一行中的这个或那个位置放置换行符”，甚至“总是用这个或那个命名方案命名变量”，都不适合我。我发现从长远来看，它弊大于利。
In your particular example I'd personally go with the fourth one:
double var = GetContext()->
CalculateValue(element, 10.0);
I've never been a fan of strictly defined code formatting standards, aside from the basic rule to always format one's code so that it makes sense (particularly to somebody who didn't write it) and is easy to read. Any overly-broad rule like "always put a line break at this or that spot in a line" or even "always name variables with this or that naming scheme" just doesn't sit right with me. I find that it does more harm than good in the long run.
It doesn't account for edge cases very well, it places the focus on the wrong thing (the points of syntax rather than the actual readable meaning and flow of the code) and it furthers the goal of commoditizing the developer to make the position as plug-and-play as possible without account for the developer's own best judgement.
(Ok, that may have turned into a bit of a rant. My apologies. But the point remains.)
Basically, without any concrete rules, the code should be made to best suit what it's trying to say in a readable manner on a case-by-case basis. Developers should use their best judgement accordingly.
I split at the spot and indent to the level necessary to render the code most readable. It's all aesthetics, so any "academic justification" is going to be no more useful than any other contrived, post-reasoned excuse to do whatever it is you arbitrarily decided to begin with.
发布评论
评论（5）
我喜欢按照绑定顺序的强度进行分割，首先最接近行尾。
所以在你的例子中我会在 = 符号处分开。如果这仍然超出了边缘，我会在 -> 处分开。
分行的想法只是为了读者的利益（因为编译可能不太关心）。我发现在心理上更容易将代码片段分成逻辑组。
I like to make the splits in strength of binding order, closest to the end of the line first.
So in your examples I would split at the = sign. If this still spilled over the margin I would split at the ->
The idea of splitting a line is solely for the benefit of readers (since the compile could care less). I find that mentally it is easier to mentally chunk pieces of code that are broken into logical groups.
在您的特定示例中，我个人会选择第四个：
除了始终格式化代码以使其有意义的基本规则之外，我从来都不喜欢严格定义的代码格式化标准（特别是对于那些不这样做的人） t write it）并且易于阅读。任何过于宽泛的规则，比如“总是在一行中的这个或那个位置放置换行符”，甚至“总是用这个或那个命名方案命名变量”，都不适合我。我发现从长远来看，它弊大于利。
它不能很好地解释边缘情况，它将重点放在错误的事情上（语法点而不是代码的实际可读含义和流程），并且它进一步实现了开发人员商品化的目标，使位置成为尽可能即插即用，而不考虑开发人员自己的最佳判断。
（好吧，这可能已经变成了一点咆哮。我很抱歉。但重点仍然存在。）
基本上，在没有任何具体规则的情况下，代码应该最适合它在案例中以可读的方式表达的内容视具体情况而定。开发人员应相应地做出最佳判断。
In your particular example I'd personally go with the fourth one:
I've never been a fan of strictly defined code formatting standards, aside from the basic rule to always format one's code so that it makes sense (particularly to somebody who didn't write it) and is easy to read. Any overly-broad rule like "always put a line break at this or that spot in a line" or even "always name variables with this or that naming scheme" just doesn't sit right with me. I find that it does more harm than good in the long run.
It doesn't account for edge cases very well, it places the focus on the wrong thing (the points of syntax rather than the actual readable meaning and flow of the code) and it furthers the goal of commoditizing the developer to make the position as plug-and-play as possible without account for the developer's own best judgement.
(Ok, that may have turned into a bit of a rant. My apologies. But the point remains.)
Basically, without any concrete rules, the code should be made to best suit what it's trying to say in a readable manner on a case-by-case basis. Developers should use their best judgement accordingly.
我当场拆分并缩进到使代码最具可读性所需的级别。这全都是美学，所以任何“学术理由”都不会比任何其他人为的、事后推理的借口更有用，无论你武断地决定开始做什么。
I split at the spot and indent to the level necessary to render the code most readable. It's all aesthetics, so any "academic justification" is going to be no more useful than any other contrived, post-reasoned excuse to do whatever it is you arbitrarily decided to begin with.
我喜欢在左括号处打破，然后在每个参数处打破
I'm a fan of breaking at opening parentheses then at each of the parameters
对于这一行：
double var = GetContext()->CalculateValue(element, 10.0, foo);我会在第一个参数之后断开链接，然后从第一个参数开始的位置开始排列后续元素，但在下一行：
如果第二行太长，则制作第三行，依此类推。
For this line:
double var = GetContext()->CalculateValue(element, 10.0, foo);I would break the linke after the first parameter, then line up subsequent elements starting where the first parameter started, but on the next line:
If the 2nd line gets too long, make a 3rd one and so on.