Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Code - White Space Survey

Code - White Space Survey

Scheduled Pinned Locked Moved The Lounge
question
47 Posts 20 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Kevin McFarlane

    Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

    G Offline
    G Offline
    Gary R Wheeler
    wrote on last edited by
    #23

    if (a == b) {
    doIt(a,b,c);
    }

    and, just to fan the flames, notice the K&R braces ... :laugh:


    Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

    K 1 Reply Last reply
    0
    • M Member 96

      In a project with as many lines of code as mine, extra whitespace probably slows down the build, load, backup and copy etc etc. I say #1 for anything more serious than a hobbyist.


      "Hello, hello, what's all this shouting, we'll have no trouble here! This is a Local Shop for Local People, there's nothing for you here!" -Edward Tattsyrup

      G Offline
      G Offline
      Gary R Wheeler
      wrote on last edited by
      #24

      Normal amounts of whitespace can't possibly affect compile times or disk space significantly. Of course, you can contrive examples where it does (1K of spaces between each token in a source file, for example). If whitespace improves your ability to read and navigate the code (it does for me), then use it.


      Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

      M 1 Reply Last reply
      0
      • K Kevin McFarlane

        Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

        R Offline
        R Offline
        Ravi Bhavnani
        wrote on last edited by
        #25

        4. if (a == b) 5. doIt (a, b, c) /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

        K 1 Reply Last reply
        0
        • G Gary R Wheeler

          if (a == b) {
          doIt(a,b,c);
          }

          and, just to fan the flames, notice the K&R braces ... :laugh:


          Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

          K Offline
          K Offline
          Kevin McFarlane
          wrote on last edited by
          #26

          The K & R braces have been discussed in an earlier thread. From my perspective you've combined two of the worst features. But these are religious wars. :) My main point was to discover the distribution of people's preferred styles. Both topics - curly brace placement and white space are relatively minor issues. Some time ago I wrote an essay discussing poor programming practices and I didn't mention these two topics - mainly because they're largely subjective. Kevin

          G J 2 Replies Last reply
          0
          • R Ravi Bhavnani

            4. if (a == b) 5. doIt (a, b, c) /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

            K Offline
            K Offline
            Kevin McFarlane
            wrote on last edited by
            #27

            5 is what I'd like to use but don't. Well done. You get 100%!:) Kevin

            R 1 Reply Last reply
            0
            • K Kevin McFarlane

              5 is what I'd like to use but don't. Well done. You get 100%!:) Kevin

              R Offline
              R Offline
              Ravi Bhavnani
              wrote on last edited by
              #28

              I know the feeling - I work with a (great) bunch of Java heads. :) But before you award me any points, I must confess I too follow K&R bracing/indenting. When reviewing other people's code, I try not to comment on whitespace or indenting. I'm happy as long as their code is readable (and of course correct, extensible and reasonably well performing). /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

              G K 2 Replies Last reply
              0
              • S Shog9 0

                3 or 4 (no big preference) 1 or 2 (depending on length and complexity of arguments) The only thing i really care about is that [if|for|while] always are followed by a space. They're not functions, and shouldn't look like function calls. Similarly, function names should never be followed by a space - i want to recognize it as a function call immediately.

                ---- Scripts i've known... CPhog 0.9.9 - make CP better. Forum Bookmark 0.2.1 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums

                G Offline
                G Offline
                Gary R Wheeler
                wrote on last edited by
                #29

                Shog9 wrote:

                The only thing i really care about is that [if|for|while] always are followed by a space. They're not functions, and shouldn't look like function calls. Similarly, function names should never be followed by a space - i want to recognize it as a function call immediately.

                I agree. I work with a guy who does the opposite, and I @!#$%#@ hate reading his code. Here's an example:

                bool condition;
                while(condition)
                {
                if( functionA ( a, b, c ) )
                {
                for(int i=1;i<3;i++)
                {
                // and so on...
                }
                }
                functionB ( c, d, e );
                }

                I don't know which I dislike more, the spacing around the parentheses or the bizarre brace indentation. Admittedly, I use K&R brace style, so I don't like the braces on separate lines anyway, but indenting them as well?


                Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                1 Reply Last reply
                0
                • K Kevin McFarlane

                  The K & R braces have been discussed in an earlier thread. From my perspective you've combined two of the worst features. But these are religious wars. :) My main point was to discover the distribution of people's preferred styles. Both topics - curly brace placement and white space are relatively minor issues. Some time ago I wrote an essay discussing poor programming practices and I didn't mention these two topics - mainly because they're largely subjective. Kevin

                  G Offline
                  G Offline
                  Gary R Wheeler
                  wrote on last edited by
                  #30

                  Kevin McFarlane wrote:

                  they're largely subjective

                  As others have no doubt said, consistency (using one style) is more important than choosing one style over another. The desired end result is to enhance readability of the code.


                  Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                  1 Reply Last reply
                  0
                  • R Ravi Bhavnani

                    I know the feeling - I work with a (great) bunch of Java heads. :) But before you award me any points, I must confess I too follow K&R bracing/indenting. When reviewing other people's code, I try not to comment on whitespace or indenting. I'm happy as long as their code is readable (and of course correct, extensible and reasonably well performing). /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

                    G Offline
                    G Offline
                    Gary R Wheeler
                    wrote on last edited by
                    #31

                    Ravi Bhavnani wrote:

                    I must confess I too follow K&R bracing/indenting

                    Ego te absolvo, Ravi.


                    Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                    R 1 Reply Last reply
                    0
                    • G Gary R Wheeler

                      Ravi Bhavnani wrote:

                      I must confess I too follow K&R bracing/indenting

                      Ego te absolvo, Ravi.


                      Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                      R Offline
                      R Offline
                      Ravi Bhavnani
                      wrote on last edited by
                      #32

                      Grazie! :rose: /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

                      1 Reply Last reply
                      0
                      • K Kevin McFarlane

                        Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

                        A Offline
                        A Offline
                        Andy Brummer
                        wrote on last edited by
                        #33

                        3 and 2, but I don't put a space after for, just if and while.

                        1 Reply Last reply
                        0
                        • R Ravi Bhavnani

                          I know the feeling - I work with a (great) bunch of Java heads. :) But before you award me any points, I must confess I too follow K&R bracing/indenting. When reviewing other people's code, I try not to comment on whitespace or indenting. I'm happy as long as their code is readable (and of course correct, extensible and reasonably well performing). /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

                          K Offline
                          K Offline
                          Kevin McFarlane
                          wrote on last edited by
                          #34

                          Ravi Bhavnani wrote:

                          But before you award me any points, I must confess I too follow K&R bracing/indenting.

                          Yes, it seems to be the Java "house style." My best friend from uni who's also a Java guy uses this style too. Though he also used it in C++.

                          Ravi Bhavnani wrote:

                          When reviewing other people's code, I try not to comment on whitespace or indenting.

                          Yes, I would ignore such issues - so long as there was some indenting. :) Kevin

                          O 1 Reply Last reply
                          0
                          • G Gary R Wheeler

                            Normal amounts of whitespace can't possibly affect compile times or disk space significantly. Of course, you can contrive examples where it does (1K of spaces between each token in a source file, for example). If whitespace improves your ability to read and navigate the code (it does for me), then use it.


                            Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                            M Offline
                            M Offline
                            Member 96
                            wrote on last edited by
                            #35

                            Gary R. Wheeler wrote:

                            If whitespace improves your ability to read and navigate the code (it does for me), then use it.

                            Whitespace does improve the ability to read code, but in gratuitous amounts it has quite the opposite affect for me. If I had to contend with this all day:

                            ///	
                            	///	RootObjectID
                            	///	
                            	public Guid	RootObjectID 
                            	{
                            		get
                            		{
                            			return mRootObjectID;
                            		}
                            		set
                            		{				
                            			mRootObjectID =	value;
                            			MarkDirty();						
                            			
                            		}
                            	}
                            

                            I would probably wear out my mouse wheel and go blind trying to find something. This on the other hand: public Guid RootObjectID {get{return mRootObjectID;} set{mRootObjectID = value;MarkDirty();}} Requires far less scrolling, is quickly understood or found in bunches and is far easier to search and replace if some re-factoring is required. Maybe it's because I'm a huge reader of novels, I find it quicker to scan a long (but not too long so it goes off screen) line of text than to muddle my way down a bunch of open space. (Damn, cp doesn't seem to be able to keep code formatting no matter what I do, you get the idea though)


                            "Hello, hello, what's all this shouting, we'll have no trouble here! This is a Local Shop for Local People, there's nothing for you here!" -Edward Tattsyrup

                            G 1 Reply Last reply
                            0
                            • K Kevin McFarlane

                              Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

                              A Offline
                              A Offline
                              Andrew Bleakley
                              wrote on last edited by
                              #36

                              4 and 2. I would prefer to be able to quickly scan my code and be able to easily read it on screen and print-out than save a compiler microseconds. Besdies I find the easier my code is to read the easier it is to see my own stupidity.

                              1 Reply Last reply
                              0
                              • K Kevin McFarlane

                                Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

                                G Offline
                                G Offline
                                Gary Kirkham
                                wrote on last edited by
                                #37

                                2 Gary Kirkham Forever Forgiven and Alive in the Spirit He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot Me blog, You read

                                1 Reply Last reply
                                0
                                • K Kevin McFarlane

                                  Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

                                  S Offline
                                  S Offline
                                  Steve Mayfield
                                  wrote on last edited by
                                  #38

                                  I use 2 & 2 for consistancy Steve

                                  1 Reply Last reply
                                  0
                                  • K Kevin McFarlane

                                    Which style do you use/prefer? 1. if(a==b) 2. if(a == b) 3. if (a==b) 4. if (a == b) I use/prefer 4. But I notice (to my dismay) that 1, 2 and 3 are very common. However, they're not the worst programming sins, i.e., I wouldn't fail a candidate because of them. 1. doIt(a,b,c) 2. doIt(a, b, c) 3. doIt( a, b, c ) 4. doIt (a,b,c) 5. doIt (a, b, c) I use 2, but would prefer to use 5. I don't do so because it's too irregular, whereas 2 is in widespread use and adequately readable. If I were programming in Eiffel I would adopt 5 because, in its context, it's widely used and is the "house style." I used 3 for a while but abandoned it for similar reasons to 5. Kevin

                                    S Offline
                                    S Offline
                                    Scott Serl
                                    wrote on last edited by
                                    #39

                                    Late reply, so nobody will see this, but: 4 & 2 Because I have not used a language where these white-space practices do not work. Many languages require white-space after tokens, so 1-3 are not valid, and I have used languages which do not permit white-space after a function name. The languages I am talking about are probably from this list (but I can't remember which ones): ANSI BASIC Fortran 77 Pascal Modula2 Forth C C++ Visual Basic (4-6) C# VB.Net

                                    K 1 Reply Last reply
                                    0
                                    • S Scott Serl

                                      Late reply, so nobody will see this, but: 4 & 2 Because I have not used a language where these white-space practices do not work. Many languages require white-space after tokens, so 1-3 are not valid, and I have used languages which do not permit white-space after a function name. The languages I am talking about are probably from this list (but I can't remember which ones): ANSI BASIC Fortran 77 Pascal Modula2 Forth C C++ Visual Basic (4-6) C# VB.Net

                                      K Offline
                                      K Offline
                                      Kevin McFarlane
                                      wrote on last edited by
                                      #40

                                      Congratulations. You win a medal. :) Kevin

                                      1 Reply Last reply
                                      0
                                      • M Member 96

                                        Gary R. Wheeler wrote:

                                        If whitespace improves your ability to read and navigate the code (it does for me), then use it.

                                        Whitespace does improve the ability to read code, but in gratuitous amounts it has quite the opposite affect for me. If I had to contend with this all day:

                                        ///	
                                        	///	RootObjectID
                                        	///	
                                        	public Guid	RootObjectID 
                                        	{
                                        		get
                                        		{
                                        			return mRootObjectID;
                                        		}
                                        		set
                                        		{				
                                        			mRootObjectID =	value;
                                        			MarkDirty();						
                                        			
                                        		}
                                        	}
                                        

                                        I would probably wear out my mouse wheel and go blind trying to find something. This on the other hand: public Guid RootObjectID {get{return mRootObjectID;} set{mRootObjectID = value;MarkDirty();}} Requires far less scrolling, is quickly understood or found in bunches and is far easier to search and replace if some re-factoring is required. Maybe it's because I'm a huge reader of novels, I find it quicker to scan a long (but not too long so it goes off screen) line of text than to muddle my way down a bunch of open space. (Damn, cp doesn't seem to be able to keep code formatting no matter what I do, you get the idea though)


                                        "Hello, hello, what's all this shouting, we'll have no trouble here! This is a Local Shop for Local People, there's nothing for you here!" -Edward Tattsyrup

                                        G Offline
                                        G Offline
                                        Gary R Wheeler
                                        wrote on last edited by
                                        #41

                                        My version of your code would be:

                                        /// RootObjectID
                                         
                                        public Guid RootObjectID {
                                         
                                        get { return mRootObjectID; }
                                         
                                        set { mRootObjectID = value;
                                        MarkDirty(); }
                                         
                                        }

                                        John Cardinal wrote:

                                        I find it quicker to scan a long (but not too long so it goes off screen) line of text

                                        Same here. You'll occasionally see the following constructs in my code:

                                        if (cond1) statement1
                                        else if (cond2) statement2
                                        else if (cond3) statement3
                                        else statementN
                                         
                                        // and
                                         
                                        switch (var) {
                                        case 1: statement1; break;
                                        case 2: statement2; break;
                                        default: statementN; break;
                                        }

                                        The statementi's in this case are usually simple single statements.

                                        John Cardinal wrote:

                                        cp doesn't seem to be able to keep code formatting no matter what I do

                                        There are a couple of tricks. First, the <pre> tag doesn't handle tabs well (your original code used them). I usually replace them with a couple of spaces. Second, the <pre> tag removes extra blank lines. You can get around that by replacing blank lines with a line that contains &nbsp;, the HTML 'non-blanking space' entity.


                                        Software Zen: delete this; // [Fold With Us!](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx)[[^](http://www.codeproject.com/script/profile/whos_who.asp?msg=1307432&id=10338#xx1307432xx "New Window")]

                                        1 Reply Last reply
                                        0
                                        • K Kevin McFarlane

                                          The K & R braces have been discussed in an earlier thread. From my perspective you've combined two of the worst features. But these are religious wars. :) My main point was to discover the distribution of people's preferred styles. Both topics - curly brace placement and white space are relatively minor issues. Some time ago I wrote an essay discussing poor programming practices and I didn't mention these two topics - mainly because they're largely subjective. Kevin

                                          J Offline
                                          J Offline
                                          jcrussell
                                          wrote on last edited by
                                          #42

                                          is the essay in public domain? I mean, can you put it somewhere for us to read? I'm always interested in knowing what constitutes poor programming practices so that I can try and avoid them myself, but with so many developers, each with their own ideas about what is good and bad, I find you really have to read a lot of material from a very wide range to get anything close to a balanced view. if you would post the essay somewhere, maybe as a CodeProject article, that would be great. /jason

                                          K 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups