Code - White Space Survey
-
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
-
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
Same here. 4 for the first, 2 for second. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
-
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
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
-
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. In my opionon the extra space in 5. doesn't enhance readability. There already is an opening bracket which seperates the function name from the arguments.
-
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
With that many lines of code, all the more reasons to make it readable, don't you think? Taking care of one whitespace during compilation is a matter of microseconds, if not nanoseconds. Surely, you'd allow an extra couple of seconds extra per milion lines of code when compiling..?
-- Pictures[^] from my Japan trip. -
4. and 2. In my opionon the extra space in 5. doesn't enhance readability. There already is an opening bracket which seperates the function name from the arguments.
-
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
Is this some kind of joke Im not getting? Please tell me you are not serious with that... :~
-
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 and 2. Mainly because that's how I've always done it, and I see no reasons to change my coding style. I've never heard of people complaining about it [edit], until now[/edit]. Especially after the invention of syntax highlighting editors.
-- Pictures[^] from my Japan trip. -- modified at 11:50 Saturday 17th December, 2005 -
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
I think 1. is the worst of the lot. Kevin
-
4. and 2. In my opionon the extra space in 5. doesn't enhance readability. There already is an opening bracket which seperates the function name from the arguments.
Robert Rohde wrote:
5. doesn't enhance readability.
I think it does slightly. But it's not a big deal. Kevin
-
Got me! When using ifs I would also always put a whitespace in between. :) I think it's really a matter of personal taste.
-
2 and 2. Mainly because that's how I've always done it, and I see no reasons to change my coding style. I've never heard of people complaining about it [edit], until now[/edit]. Especially after the invention of syntax highlighting editors.
-- Pictures[^] from my Japan trip. -- modified at 11:50 Saturday 17th December, 2005I can live with that. [smile] At least it's not 1 and 1, which are the worst IMO. Kevin
-
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
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
-
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
Kevin McFarlane wrote:
Which style do you use/prefer?
I like to use and do prefer #4. Also, #2 or #3 for functions and their parameters. PC
-
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
-
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
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
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
Oh great, now every VB programmer out there is going to read your post and take you seriously. :rolleyes: Marc VS2005 Tips & Tricks -- contributions welcome!
-
Same here. 4 for the first, 2 for second. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
4 and 2 here 2
-
With that many lines of code, all the more reasons to make it readable, don't you think? Taking care of one whitespace during compilation is a matter of microseconds, if not nanoseconds. Surely, you'd allow an extra couple of seconds extra per milion lines of code when compiling..?
-- Pictures[^] from my Japan trip.It would be an interesting test to find out, maybe some sort of macro in vs that can get rid of any possible unnecessary whitespace and compare side by side. I comment liberally, but when you're looking at a huge screen full of code it's nice to be able to see it all at once rather than scrolling all over "hell's half acre" to find it. (which, when you think about it adds a *lot* more than a few seconds, probably hours to days over the life of a project)
"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
-
Is this some kind of joke Im not getting? Please tell me you are not serious with that... :~
Serious about saving time compiling - no, serious about saving time scrolling all over the place when it could as easily fit on one screen and still be readable - yes. I *do* opt for the most compact code possible. I'm not crazy about it, for example a property has one line for the declaration, one line below for the get and one line below for the set, not all on one line, but not broken out with a single line for a parenthesis {, that's just a waste of visual acuity.
"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