Code - White Space Survey
-
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")]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
-
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
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.
-
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
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
-
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
I use 2 & 2 for consistancy Steve
-
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
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
-
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
Congratulations. You win a medal. :) Kevin
-
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
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
, 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")] -
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
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
-
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
-
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
Kevin McFarlane wrote:
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++.
I never understood the connection between language and coding style. Unless, of course, the language itself disallows / discourages specific constructs, like using spaces between function name and opening bracket in Python or Ruby. I remember a couple of Microsoft training courses I was on. On the C# training course we were told, under pain of death, to use "RaiseEvent" and not "FireEvent". Never mind, a couple of months later, during the ASP.NET course, it was "FireEvent" all the way. At least they had the good manners not to make it a big issue out of it. But the saddest thing was that a couple of "experienced" programmers asked (and they were a 100% honest!) "why?". To my mind, the coding style only has to do with consistency, readability, testability (try debugging multiple statements on the same line and see how you like it) and clarity (see Joel On Software for a few interesting points about this aspect). And, as long as the compiler/interpreter understands it, what do I care about "house style"? Just imagine that the conventions would change for each different literary style (Yes, I know, programmers only ever read IT manuals and sci-fi, but still...) OGR
-
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
jcrussell wrote:
if you would post the essay somewhere, maybe as a CodeProject article, that would be great.
I've been sitting on the essay for about a couple of years wondering what to do with it. I may put it on my personal web site. But I was also thinking about sending it to ACCU's magazine, CVu. (http://www.accu.org[^]) I could do both of course, as well as post it here (after converting it from Word). Maybe it's an idea to post it and get more feedback (and possible disagreement!:) Then I could send it to that magazine. Anyway, the article is written from the perspective of myself as code maintainer. So I highlight practices I've found which help or hinder me in that activity. Kevin
-
ogrig wrote:
It's 4 and 5 for me.
You win a gold medal! :)
ogrig wrote:
And I would fail a candidate for (1 or 3) and (1 or 4).
Blimey! I'm not as harsh as that! I think you'd end up failing quite a lot of otherwise good developers. I'd fail a candidate for something like not answering these [C++] questions correctly. 1. Declare and define inline a class that contains the following: a. An integer data member. b. A pair of functions to read and modify the data member. c. A default constructor. 2. Write a non-member function that takes an instance of the class you defined above as a parameter and makes a call to its "read" member function. Basically, I'd be looking for use of const. Kevin
-
Kevin McFarlane wrote:
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++.
I never understood the connection between language and coding style. Unless, of course, the language itself disallows / discourages specific constructs, like using spaces between function name and opening bracket in Python or Ruby. I remember a couple of Microsoft training courses I was on. On the C# training course we were told, under pain of death, to use "RaiseEvent" and not "FireEvent". Never mind, a couple of months later, during the ASP.NET course, it was "FireEvent" all the way. At least they had the good manners not to make it a big issue out of it. But the saddest thing was that a couple of "experienced" programmers asked (and they were a 100% honest!) "why?". To my mind, the coding style only has to do with consistency, readability, testability (try debugging multiple statements on the same line and see how you like it) and clarity (see Joel On Software for a few interesting points about this aspect). And, as long as the compiler/interpreter understands it, what do I care about "house style"? Just imagine that the conventions would change for each different literary style (Yes, I know, programmers only ever read IT manuals and sci-fi, but still...) OGR
ogrig wrote:
I never understood the connection between language and coding style.
Maybe it's down to the style used by the original community of developers or even that of the language inventor.
ogrig wrote:
To my mind, the coding style only has to do with consistency, readability, testability (try debugging multiple statements on the same line and see how you like it)
Yes, I dislike more than one statement per line. Consistency is also highly desirable and I can usually live with my unfavourite styles if they're consistent.
ogrig wrote:
And, as long as the compiler/interpreter understands it, what do I care about "house style"?
The house style thing was just an observation. A few years ago when I was doing a little Java and more JavaScript, I notice the widespread use of K & R and decided I would go along with it. But then I gave up and reverted to my preferred style. However, when having to maintain code I generally tend to follow the style of the original source and that includes use of conventions such as Hungarian. I used to love Hungarian but now hate it. But if the original source uses it I go along with it. Kevin