Wednesday, August 5, 2009

Automation - The Right Way to Achieve Standards

Generally I think coding standards are worthless, but that is an exaggeration, as I love best practices, and love quality code. There are always the infamous discussions of should it be "ID" or "Id." An example is ProjectID or ProjectId... Ok in the old days this mattered but with most modern languages this is not how people should be spending there time or this should be the icing on the cake after you already know you can create clean code as a team. There is a decent chance people will change and things will change and somehow you will likely have both in your project, sure there are exceptions if you really want the police to come check or you run fxcop.

I would suggest if you want a standard in this regard, use something that catches it at the source. Resharper, tells you immediately after you type it. In this case everyone on your project must use Resharper and you tell everyone follow Resharper rules and there you go, you can easily get 100% compliance.

That is all a side track from the real point which of standards which is: Over the lifetime of your application you want "maintainable" code, what else really matters? How pretty it looks with consistent "Id?" I try to follow those rules myself but FOCUS on getting the big picture right and once you have that mastered move on to the finer details.

So what does "maintainable" code look like? Ideally methods you can basically understand what it is doing in 30 seconds or so. Definitely not something that takes 10 minutes or more and you still are not sure if you understand it totally. Now there could be 20 small methods that each one on its own is understandable but one big 300 line method is not. Or take it even smaller there could be 3 20 lines that are and 1 60 that is not. So from my perspective 3 key ingredients there. Reduce lines of code, cyclomatic complexity and nesting depth, that will get you 90% right there. You want 100% compliance, automate Ndepend with Continuous Integration, and get some automated enforcemnt... Problem solved an no manual work involved other then enforcing or inspiring compliance.

So what else? There are many other things that could equate to bad code, but next on my list is duplication of logic, bad names and wrong placement the list could go on. Duplication can be reviewed automatically too :) (see simian and manually see clone detective). Names and bad placement that is manual code review all the way... Now creating small methods makes them potentially reusable, and you can never reuse that 300 line method, or very rarely.

Anyway I just want to put a quick note that you should focus on the big picture, only make standards that can be enforced automatically. Make the rest best practices, and only spend time with them when your big picture is working well. Also read Clean Code and another one for big picture that is great is 97 Things Every Software Architect should know

Good luck.

No comments:

Post a Comment