C# coding style conventions

I like how the main body of the book is divided into 9 chapters, and Chapter 9 is followed by Chapter A. Some would consider it an appendix, others – a sequential hexadecimal numbering. Pretty neat.

As for the coding conventions, they don’t match my coding conventions, and therefore of course I don’t like them. I support or at least don’t mind most of the conventions specified, but there are some I specifically don’t accept. For starters, the curly braces are put like in Java:

if(someExpression){
    ...
}

While I consider this style acceptable, personally I don’t like it, and if someone tried to force it upon me, I would not feel comfortable. Consequently, I would not try to force my curly brace style on someone who prefers the Java style. Having one style is important, but avoiding silly style wars is much more important. The only requirement is – the style per file should be consistent. If I make minor changes to a file, I follow whatever style is used there. If I create a new file, or significantly rewrite an existing one, I use “curly on a separate line” style.

Furthermore, the authors seem to hate spaces and insist on writing things like while(x==y){, without a single space. In my world, this is insane. The correct way should be while (x==y), and if they must put an opening curly on the same, line then while (x==y) {.

p. 277: Do use C# aliases instead of Framework type names. For example use int instead of Int32. I support that with one exception: when calling static methods like String.Format(), or Int32.Parse() I use the Framework name. string.Format() just looks unnatural to me.

p. 277: It would be ideal, if from reading the comments alone, someone other than the author could understand the function’s behavior and purpose.. I hope they did not mean it. Otherwise, ideal code would look something like this:

// This function returns a sine of the argument by computing the Tailor series to the 7th member
double qpwoeiqp( double weproi )
{
    double asdfg = werpoi;
    double mes = werpoi;
    double pok = werpoi*weproi;
    double qweqwe = 1.0;
    for (int cvb = 1; cvb < 7; ++cvb)
    {
        mes *= pok;
        qweqwe *= - (cvb*2)*(cvb*2+1);
        asdfg += mes/qweqwe;
    }

    return asdfg;
}

Ideally, we would not need comments at all. Someone other than the author could deduce the function purpose by looking at the function name alone, and the function behavior by looking at the code, that should be neither long, nor tricky.

p. 278: Avoid multiline syntax for comments. The single-line syntax is preferred even when a comment spans multiple lines. I may be a brontosaurus, but I see nothing wrong with the multi-line syntax.

File Organization

Do not have more than one public type in a source file, do name the source file with the name of the public type it contains, do organize the dircetory hierarchy just like the namespace hierarchy..., do pretend you are in Java 🙂 I mean, I support these particular guidelines 100%, but it sounds kinda funny, doesn't it.

Consider grouping members into the following sections... Consider organizing members of each group in alphabetical order. I'd say: if it comes to organizing the members in alphabetical order, your class is too big. Consider breaking it up.