Home>

I have the curly bracket start position for all functions on the line after the parenthesis, what is the benefit of having the parenthesis right next to it?
Is it for those who are easier to see?

c c++
  • Answer # 1

    if,for,while, etc. I think there is a certain attitude. Please separate these if you want to separate lines.

    By the way, there is also a reason for writing "separate lines only when function is defined", and in old C (before ANSI C), the function argument list is

    void foo (hoge, fuga, ...) // The argument is just a name declaration
    int hoge, fuga;// type declaration
    ...
    {
       ...
    }
    Because it was the syntax

    , I think that function definitions are now written with natural curly braces on separate lines, and the remnants still continue ... Other than function definitions, writing on the same line is said to reduce the number of lines when publishing on paper.

    I didn't understand this meaning when I first started learning, so I remembered how to write it next to the parenthesis without separating the lines.

    Unsatisfied with K&R style-Ryo's growth record
    Indentation style-Wikipedia
    Programming language C-Wikipedia

  • Answer # 2

    There are various people, so there are various ways.
    Man page of INDENT

    The reason for writing

    {on the same line is to reduce the number of lines. Since the screen is finite, reducing the number of lines with less information (lines with only parentheses) increases the amount of code that can be viewed on one screen, so it is more efficient when reading and debugging. .
    Also, in the style of writing{on the same line asif,while, etc., it means to unify it.

  • Answer # 3

    Hello.

    As there are already multiple answers, writing{on the same line as the function definition has the advantage of simplifying the formatting rules and reducing the number of lines. I think this is a useful perspective.
    However, I have a personal view, but I think that the disadvantage is more painful than the advantage, so I will supplement the opposite view.

    If you write a function with a complicated argument or a complicated conditional expression in C ++, a long sentence is very painful.
    The following is just a sample now, but there are quite a few things that go far beyond this in actual programming situations.

    # include
    #include
    #include
    #include

    std :: listextract (std :: vectorconst&iVector, std :: functioniCondition) {     std :: listret;     for (int elem: iVector) {         if (! iCondition (elem)) {             ret.push_front (elem);         }         if (iCondition (elem)) {ret.push_back (elem);         }     }     return ret; } int main () {     auto extracted = extract ({-152, 44, 9, -29, 33},  [] (int x) {return x>= 0;});     for (int item: extracted) {         std :: cout<

    In such a case, I think that there are many people who make a line break for each parameter, but at that time the line) {is unclear enough to make you cry. I'm worried about whether to do it each time.

    Furthermore, the above is still good because there are only a few for blocks and if blocks, but if you go beyond a few lines to more than a dozen lines, it will be easy to overlook block breaks, but{and}indentation is a countermeasure.

    # include
    #include
    #include
    #include

    std :: listextract (     std :: vectorconst&iVector,     std :: functioniCondition ) {     std :: listret;     for (int elem: iVector)     {         if (! iCondition (elem))         {             ret.push_front (elem);}         if (iCondition (elem))         {             ret.push_back (elem);         }     }     return ret; } int main () {     auto extracted = extract ({-152, 44, 9, -29, 33},  [] (int x) {return x>= 0;});     for (int item: extracted)     {         std :: cout<

    However, the following is too long and it is annoying because it is at the "unsightly" level, but I do not worry about dividing long sentences and avoiding oversight of blocks.

    if (foo)
    {
        bar ();
    }
    else
    {
        baz ();
    }

  • Answer # 4

    Everyone feels it ’s easy to see. It's hard to imagine for today's young people, but in the past, "80 columns x 25 lines" was the maximum number of characters that could be displayed on the screen. It tried to reduce the number of lines as much as possible to fit in it. That habit is still going on. Some coding conventions have decided that "a line is 80 characters or less".

    Well, many people probably didn't care about the merits, but the source code that was just referenced during the study was in the style of writing{on the same line as the control statement. I think it's just that, but I'm just writing it. After that, most modern text editors have code formatting, but the default settings are often on the same line as the control statement.

    By the way, I also write{after a line break. Since the block range can be known in an instant, there are advantages that it is easy to grasp the control structure of the program and that editing in line units is easy. When debugging, it is easy to do things like "I want to temporarily comment out the if statement and execute the contents of the block".

  • Answer # 5

    That's why people like it.
    It ’s easier to see the same line without increasing the number of lines.