I’m doing a new thing now!

If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.

Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)

One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.

Why you shouldn’t have “coding standards”

Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.

Sure. There’s nothing wrong with that if it makes you feel better.

The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.

Here’s what I really mean.

Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…

…Let’s Have Standards.

In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.

I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.

• If your architecture is too complicated, reduce the architecture.
• If you lack unit tests, build code with unit tests.
• If your code is too tightly coupled, think about where the seams should go.
• If it’s hard to find the class you want, pick better class names.
• If you have a lot of duplicated code, refactor it to remove the duplication.
• If your problem is excessive defects, then “standards” aren’t going to help at all.

So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?

Here. Let’s make it easy.

Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.

The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.

I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.