Coding Style - White space

Post by **jordansparks** » Wed Jun 20, 2007 8:39 am

In r430, fcarlier comments, "Ran CTRL+K,CTRL+D on this document. This auto-updates the lay-out." The result seems to be an increase in white space. I'm OK with this. (of course, I don't think it's his intention to apply such a sweeping change to our trunk). I'll be rewriting the Coding Style page to conform more to industry standards. However, I would strongly prefer to keep the restriction in place to not allow extra blank lines within methods. It's a totally inefficient waste of space. And, of course, leading tabs instead of spaces will continue to be important.

fcarlier · Post by **fcarlier** » Thu Jun 21, 2007 12:04 am

Yes, of course this is on my branch and not the trunk.

About blank lines in methods, I usually prefer them because that way, your code gets structured into smaller blocks -- just like you structure text into paragraphs. Of course, when moving my changes into the trunk, I can always remove it.

What CTRL K, CTRL D does, is re-formatting the code you have to the style you defined in the Visual Studio options. For example, it will automatically update bracing style, indentation (replace spaces by tabs and vice versa) and so on.
It also adds whitespace between operators and so on (something Open Dental currently doesn't have).

I did this because the indentation on some methods in ContrDocs was off. This fixed that (but in a rather intrusive way).

Post by **jordansparks** » Thu Jun 21, 2007 9:20 am

I'm a bit fanatical about getting the indentation correct. So if it's not right someplace, then explicitly fixing it is the thing to do. And also informing whoever got it wrong.

ithcy · Post by **ithcy** » Wed Jul 25, 2007 2:26 pm

??

all whitespace is completely tossed out by the compiler, and it's only one byte per linebreak in the source (er, 2 bytes on windows)... not really a waste of space if it helps you read the code, is it?

Post by **jordansparks** » Wed Jul 25, 2007 2:52 pm

Reduction of white space isn't to save space in the compiled program. Instead, it serves these purposes:
1. Consistency. The more similar all the code in the program is, the more efficient it is for us.
2. Readability. If blank lines are left in methods, it makes it hard to tell where the divisions between methods are.
3. Compactness. Less scrolling. I hate to scroll.

Frederik can probably get away with non-compliant white spacing because I value the high quality of his code enough not to make a big deal about it. But if anyone else leaves blank lines, you can bet I will let them know about it. And I will admit that other variations in white space are becoming less important as we move to much larger monitors (I have a 28"). That's why most of the white space guidelines are now gone from our website and it's much more relaxed.