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

This is a discussion on [Weird Question] Where to break a line in C++ code? within the C++ Programming forums, part of the General Programming Boards category; I have a weird question: I am using emacs and g++ to code C++ code in linux. Sometimes a line ...

  1. #1
    Registered User
    Join Date
    Apr 2007
    Posts
    284

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

    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);

  2. #2
    Fear the Reaper...
    Join Date
    Aug 2005
    Location
    Toronto, Ontario, Canada
    Posts
    625
    Have you tried putting the [Enter]'s where you want and seeing if it still compiles ?
    Teacher: "You connect with Internet Explorer, but what is your browser? You know, Yahoo, Webcrawler...?" It's great to see the educational system moving in the right direction

  3. #3
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,821
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Registered User
    Join Date
    Apr 2007
    Posts
    284
    Quote Originally Posted by Happy_Reaper View Post
    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

  5. #5
    Registered User
    Join Date
    Apr 2007
    Posts
    284
    Quote Originally Posted by Salem View Post
    > 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.

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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:
      Code:
      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.
      Code:
      //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.
    Last edited by VirtualAce; 11-22-2007 at 10:40 AM.

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,264
    MSVC++ compilers allow you to place newlines when using literal strings.
    That is standard C and standard C++, not an MSVC extension.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I was not aware that was standard. Nice and thanks for clearing that up.

  10. #10
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Yes but if you add in all the windows that MSVS likes to add to your environment 80 characters is quite enough.

  12. #12
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Bubba View Post
    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.

  13. #13
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,821
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  14. #14
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,270
    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:

    Code:
    x = this_is_a(1, 2, very_long(line(3, 4, 5)));
    You might break it as:

    Code:
    x = this_is_a(1, 2,
                  very_long(line(3, 4, 5)));
    Or less preferably at a deeper nest level, like this:

    Code:
    x = this_is_a(1, 2, very_long(line(3,
                                       4, 5)));
    For an if-statement:

    Code:
    if(initializer;
       condition;
       increment)
    {
    }
    For a long expression involving operators:

    Code:
    x = some_thing(x, 1, 2) && some_other_thing() && !yet_another_thing();
    Break as:

    Code:
    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:

    Code:
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Another syntax error
    By caldeira in forum C Programming
    Replies: 31
    Last Post: 09-05-2008, 02:01 AM
  2. code review
    By hamsteroid in forum C Programming
    Replies: 6
    Last Post: 04-04-2007, 01:23 PM
  3. ascii rpg help
    By aaron11193 in forum C Programming
    Replies: 18
    Last Post: 10-29-2006, 01:45 AM
  4. Converting Numbers to Words
    By denizengt in forum C Programming
    Replies: 20
    Last Post: 11-05-2003, 09:19 PM
  5. A simple array question
    By frenchfry164 in forum C++ Programming
    Replies: 7
    Last Post: 11-25-2001, 04:13 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21