Skip to main content
Engineering LibreTexts

2.6: The Great Bracket Debate

  • Page ID
    29019
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    The Great Bracket Debate

    It really isn't that big a deal - but it continues to be a point of disagreement across the software developers' world: Where do the curly brackets belong when I write my code. Once again, for you as a software developer in the world, someone else will probably make that decision for the project you are working one.

    But, let us take a few moments to examine what the options are.

    The following code is a common example of how people write the code. Notice that the first { is on the line AFTER the function definition. On the If/else statements the opening bracket is at the end of the line. Both of these are valid ways to code the brackets.

    void someFunction() 
     { 
         if (condition()) { 
             cout << "condition was true" << endl; 
         } else { 
             cout << "condition was false" << endl; 
         } 
     } 

    Another frequent formatting is that brackets are always on a line by themselves. Some say this make code easy to read and debug as you can see the matching brackets quite easily.

    void someFunction() 
     { 
         if (condition()) 
         { 
             cout << "condition was true" << endl; 
         } 
         else 
         { 
             cout << "condition was false" << endl; 
         } 
     } 

    The code below shows how some programmers seem to go make it difficult to read their code....this is a valid way to code, but does make it a bit it more difficult to read.

    void someFunction() 
     { 
         if (condition()) 
            { 
                cout << "condition was true" << endl; 
            } 
         else 
            { 
                cout << "condition was false" << endl; 
            } 
     } 

    For this class, I will not tell you which method to use, but I suggest you NOT make it difficult for me or my grader to grade your code...do so may cost you points!!


    This page titled 2.6: The Great Bracket Debate is shared under a CC BY-SA license and was authored, remixed, and/or curated by Patrick McClanahan.

    • Was this article helpful?