Well, here we get to the fun.
First of all, I must say that you
must have a style guide for your company or project, and that will be
your guide. There are many things at guidelines that can be considered subjective, and such things will vary accordingly depending on the reader / user.
I've put a link to a very comprehensive guide for C# from Philips, it is pretty C# specific, but many things can be applied to any object oriented language. I have to say that I don't agree to every point at it, and that I miss some explanations, but this is logical since it's something imposed to a development group and not a discussion, like this.
I find that this document mixes concepts on naming, coding format and coding style, which are different for me. I've talked a little about naming, to which I'll come back later. Coding format talks about the appearance, and how to improve code readability, and it's less language specific. Code style is more about coding techniques, and how to write better code. Every one of them try to improve code quality, but from different point of views. All are essential, and in concrete cases like this it may make sense to mix them, but I prefer to keep them apart.
I will address Code Format first, starting with things I think are
objective, explaining their rationale. Later I will come to the subjective things, mainly related to spacing and length.
Afterwards I will address Code Style, splitting it the same way.
Remember, this is my blog and, so, I write here my own thoughts, which can be different from yours. I am usually in charge of defining this kind of things at work, and enforce them. Yes, enforce; when you are working for a company, you
must adhere to the company's guidelines, even if they differ from yours. When you are coding at home, or you leave that company, you can use your own rules.
Let's start.
Declaring variables
I fully agree with the given document that variables must be declared where they are used, instead of putting all of them at the method beginning. This is one of the improvements that came with C++ over C, and a good one. If you declare a variable next to the block where it's used you ease refactoring, as you can take the whole block at once at move it to another method, for example; and if you happen to remove the block you won't miss the variable. More over, placing the variable next to the block using it makes it easier to understand its purpose.
Control blocks
Again I agree, that
every control primitive (if, while, etc.)
must be followed by a control block, even if it's empty. Even though C++, C# and Java allow to use no braces for simple control blocks (one line) that it's very error prone: if you later add a line to the block is rather easy to forget about the braces, it will compile, but the new line will not be in the block and the program will not work as expected. These kinds of errors are usually very difficult to spot.
Use spaces, not tabs
Many will say this is subjective, I say it's not. The reason is simple: spaces are the only way to guarantee that indentation will keep consistent at different environments. Typically, different systems show tabs different, and that applies not only when going from Windows to Unix, for example, but even at the same operating system between different programs. The subjective thing here is how many spaces we should use to perform indentation. I use four spaces, but
that is subjective.
Indentation
You must use a good and consistent indentation style. That's objective. The rest about it is subjective, and I feel I will make a single post on the subject with my own preferences. Indentation is much related to the maximum line length, which will be addressed at my next post.
And I think these are the few objective things about Code Format.
Philps' C# Coding Guidelines
