by Don Jones

I’ve recently been in a few… let’s call them “discussions” with some of my consulting clients. The discussions have all been on the topic of code quality, and it’s been an interesting look into how a production development ship often works.

Take a recent instance when I was discussing coding standards with a developer and his manager. Both of them were spending a great deal of time arguing about the right coding standards, such as variable naming conventions. I asked why they were putting so much effort into this discussion since their application was widely viewed by the rest of the company as being of pretty poor quality. “Because,” they said, almost in unison, “better naming conventions means better code quality!”

Um, okay. Here’s the thing: People who write about code quality-like me-do write about coding standards like formatting and variable naming conventions. But we do not write about these things because they are an indicator of higher-quality code; we write about them because they help lead to higher-quality code.

Let me explain: If I give you a hunk of code that looks like this:

If ($g) { $this->mod($y,$x); } else { return $x; }

It’s a little difficult to follow. You can’t tell what’s going on, you can’t tell what you should expect, and you really can’t offer any input on the “quality” of the code. Now consider this:

If ($logged_in) {

$this->register_user($user_id,$user_name);

} else {

$return $user_name;

}

Without seeing any of the application, you can start to make some assumptions about what the code is doing, or at least what it’s supposed to do. That’s what coding standards do: They make the code easier for a human being to follow so that peer reviews can be quicker and more productive, developers can help maintain and develop each others’ code more easily, and long-term maintenance of the code is less likely to introduce major new errors.

But there’s no point in spending a ton of time on your coding standards. Pick up a book on coding best practices and just use whatever the author recommends. It doesn’t ultimately matter because unless you’re doing those other things-such as peer reviews and code maintenance-then you’re never going to see an increase in quality. Coding standards are an enabler of quality, not a symptom of it, and certainly not a causal factor.

Always keep in mind that there are only two ways to objectively measure quality in an application: Does it do what the business needs? Do users complain about it? A “yes” to the first question and a “no” to the second means you’ve got a quality app, whether your variables are named “x” or “mean_time_to_complete.” Neither the business nor your end users can perceive things like variable names, so factors such as variable names therefore do not contribute to quality. They can just make it easier to conduct other activities that do contribute to quality.

So in this instance, I told the developer, and his boss, to knock it off and go peer-review some code.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.