[Weird Question] Where to break a line in C++ code?

[meili100]

I have a weird question:
I am using emacs and g++ to code C++ code in linux. Sometimes a line is too long to fit in a screen, I would like to break a line with RETURN key but I don't want to offend the compiler. Does anybody know the rule where to break a line in C++ code?

For example, can I break the line at the following <break> points?

for (int verylongname=0; verylongname<100; <BREAK> verylongname++)
bool verylongfunctionname<BREAK>(int verylong1, <BREAK> string verylong2);

[Happy_Reaper]

Have you tried putting the [Enter]'s where you want and seeing if it still compiles ?

[Salem]

> For example, can I break the line at the following <break> points?
Yes, anywhere you could type a space, you can also type a newline.

It's also the place where you could insert a comment if you wanted to.

The only place you need to be careful is with multi-line #define macros.

[meili100]

Have you tried putting the [Enter]'s where you want and seeing if it still compiles ?

I did. I post the question for a general breaking rule

[meili100]

> For example, can I break the line at the following <break> points?
Yes, anywhere you could type a space, you can also type a newline.

It's also the place where you could insert a comment if you wanted to.

The only place you need to be careful is with multi-line #define macros.

Thank you.

[matsp]

Obviously, another consideration, other than "where can I put a newline", is "where is a GOOD place to put a newline".

This is a style issue. If you put newlines in the right place, it makes the code more readable than if you just put them somewhere randomly.

--
Mats

[VirtualAce]

Good places for newlines IMO:

• After conditional operators like || and &&. I don't recommend putting them after bitwise operators like (| and &) because it makes the code confusing.
• After assignment operators if and only if the RVALUE of the assignment does not fit on the line.
• In function calls and enums after comma separators. This greatly enhances readability when you have tons of parameters being passed to a function or a function takes tons of parameters, or an enum that has many enumerations.
• After each member variable in a class. Greatly enhances readability.
• If an inline class function will not fit on one line you should place the entire function below the prototype in the class. If the function is too long, it probably should not have the definition in the class.
• In template functions I always place a newline after template <class T>. The rest of the function is essentially the same as a normal function.
• In general it is not a good idea to have one line with 80 or more characters. These lines should be broken up.
• MSVC++ compilers allow you to place newlines when using literal strings. Example:
  

  CString string("This is"
                         " one line of text");

  The compiler will concatenate these lines which is very handy. I have not been able to duplicate this behavior in the C# compiler. This feature is also fairly dependent on compiler implementations so I would not rely on it.
• Between sections of code that perform different operations inside the same function.
  

  //Do Foo 
  int x = some_value;
  Foo(x);
  
  //Now do Bar
  int y = some_value;
  Bar(y);
  
  //Now do something else
  ...
  ...

  When your program gets larger this will help you differentiate different operations that are being performed in a function. Normally I try to create functions that do exactly one operation and do it very well. However, there are times when that one operation requires significant setup inside the function and it does not make sense to put the setup code elsewhere.

That is certainly not an exhaustive list but I hope it helps. It comes down to a style issue but I find that most programmers tend to adhere to a fairly common unwritten standard. There are exceptions of course.

[laserlight]

MSVC++ compilers allow you to place newlines when using literal strings.

That is standard C and standard C++, not an MSVC extension.

[VirtualAce]

I was not aware that was standard. Nice and thanks for clearing that up.

[cpjust]

In general it is not a good idea to have one line with 80 or more characters. These lines should be broken up.

I'm not so sure how relevant this one is today? I believe most people are using monitors with high enough resolutions that they can easily fit more than 80 characters in one screen width. At my resolution 80 characters isn't even half way across the screen.

[VirtualAce]

Yes but if you add in all the windows that MSVS likes to add to your environment 80 characters is quite enough.

[cpjust]

Yes but if you add in all the windows that MSVS likes to add to your environment 80 characters is quite enough.

Well in any case, I'd rate that as lower priority goal, but I certainly wouldn't make it a strong rule. However, if your code has a lot of very long lines, that could be signs of bad judgement (either doing too many things in one statement, or using excessively long variable & function names).
Most of the time you don't need to see every single line of code all at once, and when you do, it's easy to scroll right.

[Salem]

80 is good
- it's traditional,
- it will look good on a forum,
- it will look good in an email,
- it will look good on usenet,
- it will look good when doing side-by-side differences,
- every single code editor will at least manage 80 chars without making a mess of it.

Just consider it to be another portability issue. It may be compiled today using a fancy windows IDE, but tomorrow it might be someone using vi on a terminal.

[brewbuck]

There are a lot of natural places to break lines. Directly after a semicolon or comma, or directly before a low-precedence operator are the most preferable I think. Also, when nested inside parentheses, try to break lines at the shallower nesting levels, not the deeper ones.

For instance:

x = this_is_a(1, 2, very_long(line(3, 4, 5)));

You might break it as:

x = this_is_a(1, 2,
              very_long(line(3, 4, 5)));

Or less preferably at a deeper nest level, like this:

x = this_is_a(1, 2, very_long(line(3,
                                   4, 5)));

For an if-statement:

if(initializer;
   condition;
   increment)
{
}

For a long expression involving operators:

x = some_thing(x, 1, 2) && some_other_thing() && !yet_another_thing();

Break as:

x = some_thing(x, 1, 2) && some_other_thing()
    && !yet_another_thing();

Or if there are a whole bunch of conditions, line it up neat like:

if(   condition1
   && condition2
   && condition3
   && condition4)
{
}

The advantage of breaking BEFORE an operator is that you can immediately tell, just by looking at that single line, that it is a continuation of a previous line. The indentation should also help tell you that it's a continuation.

As for specifically how to indent, and how to line up continuation lines, I think that's purely a matter of preference, but I DO think it is important to pick some consistent alignment strategy, and to break BEFORE operators, not after them.