Where do you like to split long lines? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 12 years ago.

Improve this question

For manually wrapping long lines, what is your personal heur开发者_StackOverflowistic for choosing places to break a line?

Assuming this line is too long, where might you break it and it what order of precedence?

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

Most people agree about separating parameters per line:

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

Does anyone break at an opening paren?

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

But how bout with a dereferencing operator (or .):

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

or would you:

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

Any different for the assignment operator?

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

or

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

Any others?

If your system is procedural, you could answer like this:

1. Parameter names at comma
2. Before a -> or . operator
3. After an assignment operator

Or just post some example code!

Bonus points if you can academically justify your breaking decision.

---

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.

---

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.

---

I'm a fan of breaking at opening parentheses then at each of the parameters

---

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:

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

If the 2nd line gets too long, make a 3rd one and so on.