Blake O'Hare .com

Blake's C# Style Guidelines

Since I will be leaving the world of C# fairly soon, I figured I'd store my knowledge in a time-capsule somewhere. And that's what this is. Not all of these are specific to C#, so all you Java people can benefit. Also even other languages, too.

Put it in a separate assembly

Not everything. But if you can put something in a separate assembly without making that assembly have a reference back to the rest of your code, at least draw a box and arrow on your whiteboard and stare at it for a few minutes while drinking a cup of tea and see if it gives you a warm and fuzzy feeling. Don't over do it, of course. Just get in the habit of thinking about it. Force yourself to write code that is incapable of turning into spaghetti code.

Don't put event handlers everywhere

There's a better way. I promise. Just take a step back and think about it.

Linq is awesome

If you don't know how to use Linq, then learn it and keep it in your toolbox. The instances where it shortens code are numerous. It also lets you put lots of things into one line without making it unreadable. In fact, often times these 1-line pieces of Linq code read like English more than traditional code.

// Create a list of just the even numbers from a list of integers
private List<int> DoStuff(List<int> nums)
{
    List<int> output = new List<int>();
    for (int i = 0; i < nums.Count; ++i)
    {
        if (nums[i] % 2 == 0)
        {
            output.Add(nums[i]);
        }
    }
    return output;
}

private List<int> DoStuffWithLinq(List<int> nums)
{
    return new List<int>(
        nums.Where<int>(num => num % 2 == 0));
}


If your function is longer than 100 lines, you have failed as a human being

I mean it.

If your class is longer than 1000 lines, you have failed as a human being

That, too.

Keystrokes are free

So rather than putting a comment in the code, make an overly descriptive variable name. Variable names can be really really long. I'd rather see code that is self-evident than cryptic code with a story next to it. On the same token, don't chain a bunch of crap together into one line for no good reason. If there's specific meaning to the first half of the line of code, then put it into a variable with a descriptive name that explains what the meaning is. Then use the variable in the next line to do the 2nd half of whatever it was you were doing. If I have to scroll horizontally, God kills a kitten. Which brings me to...

Vertical code is easy-to-read code

Every logical thought you had while writing code should appear on its own line. If statement conditions that are chained by &&'s? Separate lines. Ternary expressions that aren't stupidly simple like adding an 's' to a string for plurarl? Separate lines. I've always been fond of this formatting:
int listLength = list != null
  ? list.Count
  : 0;


There is no excuse to block the UI thread.

Ever. Use a background worker if you must. I even wrote an article about it. No UI operation should be complicated enough that it takes a noticeable amount of time for it to complete. Your UI-less model should take the brunt of the computation, finish, and then send it off to the UI for quick rendering.

Bindings make life simple in 12% of cases

It's okay to use a WPF binding when they're quick and direct. But after that, they're bloody impossible to debug and generally make you want to gouge your eyes out with a #2 pencil. Binding typos rarely cause any sort of error to be reported. It will just not work. Bad data context? No error. It just won't work. Bad template parent tracing? No error. It just won't work. The list goes on and on. So save 4 years of your life and use them during those 12% of cases where they're so stupidly simple there's no way they can go wrong. For everything else, just do it the old fashioned way.

Make everything private by default.

Once you need something, then make it internal or protected. If internal isn't good enough for you, then make it public. Don't make anything public until you need to.

Write something cool and useful? Save it as a DLL.

After a year of writing Silverlight games, I realized 80% of the code I had written for a previous game before. So now I have Gamelight. I also have a bitmap and wave file encoder/decoder amongst other useful things I keep pulling out of my accumulated toolbox.

VS is magic! MAGIC!

Trailing spaces at the end of lines bother me. Or when people mix and match curly brace styles? Are they at the end of the line or on their own line? Who knows! Here's a trick. Make sure your tab settings are set sanely in the options menu and then go to the bottom of the file and re-type the last curly brace. It will go through the whole document and format everything consistently. No more stray spaces.