Fog Creek Software
Discussion Board

Code Quality From Another Perspective

I've just read through the thread about measuring code quality. I agree with people that it's hard (maybe impossible) to assign a 'figure of merit' or some absolute measure of the quality of a given piece of code.

But does anyone have any ideas about identifying problem areas *within your own team's codebase*?

I don't really care whether any given piece of code is as high-quality as something NASA would write. That's meaningless to me.

But I'd like to be able to compare two parts of my own source code, and determine which one has the higher quality. Then I'd know where to concentrate improvement efforts to get the most 'bang for the buck'. Also, if those two components were developed using different methodologies, I'd have some idea about which was the most effective.

Do you guys just track the number of bugs raised by component, or do you do something more complex?

Darren Collins
Thursday, June 05, 2003

Often the customer or integrator has the best perspective. My employer builds enterprise applications, which each engineer owning a different portion of the architecture. The guy who installs our software at the customer site and deals with support issues has a good idea of the relative quality of each person's code.

Friday, June 06, 2003

A long winded answer, worth no more than you paid for it.

Friday, June 06, 2003

***But does anyone have any ideas about identifying problem areas *within your own team's codebase*? ****

There are MY thumb rules/guidelines to sniff out bad code.

1. Look for big functions/big files e.g. a single function with 200 lines or 3000 line file etc
2.  Lots of parameters passed to one function (e.g. functions taking  9-10 parameters)
3.  Big switch/case or if-elseif conditions.
4.  Duplicate code with minor differences. e.g. functions with almost similar code but 3/4 lines are diffrent.
5.  Complex code/logic. (this is generally found in large functions).
6.  Function names like 'DoSomething', 'AddNumber' etc. Describing action and not intent of the function.
7.  Lots of Get functions in a class
8.  public member variables.
9.  Lots of global functions using public member variable of classes or using Get functions of classes
10.  Duplication of information (e.g. me information stored in two classes or two variables of same class).

Remember, all these are INDICATORs. and NOT absolute Rules.

Nitin Bhide
Friday, June 06, 2003

Nitin, having introduced many of the things you mentioned to our latest project I am feeling a bit sore  :-O

Ultimately many of the conditional yuck arose through bug fixing and having to do a lot of wrapping/abstracting code to make our code operate in 2 modes (an embedded server & as a java applet).

A lot of the 'cleanest' code is stuff that has low value and has accrued almost no changes or bug fixes. In my experience things like classes that contain the mainline or similar initialiser, significant GUI classes and Utility classes typically build up a lot of cruft.

A lot of the cruftiest code has a large testing investment. So while following the advice in Code Complete is part of the quality equation, it is only one part.

Friday, June 06, 2003

Agreed with Nitin -- there are certain automatic indicators of bad code, but no absolute rules.

First, you have to define what "high-quality" means.  I value "straightforwardness" -- the code may not be simple in an absolute sense, but it should be clear and completely understandable as quickly as possible.  Ergo, I want to avoid long functions and complex logical statements.

Here is my list of code smells (automatically sniffed by a script):

* Any line of code with more than 3 levels of nesting.
* Any function definition with more than 5 parameters.
* Any function more than 25 lines long.
* Any use of globals.
* Any if() statement with more than 2 expressions (e.g., "a = b AND b = c" is okay, but not "a = b AND b = c OR d != e").

Note that it's okay to violate these rules if there's a very good reason to.  But the vast majority of code shouldn't.

Brent P. Newhall
Friday, June 06, 2003

A lot of these rules really lead back to the excellent Refactoring book by Martin Fowler. He gives the "sniff test" of when code might need to be refactored, and a bunch of mechanical refactorings that can be done.

That's not to say that code that needs to be refactored is necessarily bad. From the simplest measure, the question is: does the code properly perform its job? Refactoring can take that working code and make it easier to maintain and reuse.

Brad Wilson (
Friday, June 06, 2003


"does the code properly perform its job?"

When? Today? Tomorrow? 2 years from now after umpteen releases?

Ideally the code works today (HA!), but can you build on it and still use it a  few releases later?

I have to work with code that was developed at least as early as the 80's (maybe even before). As we build on it, expanding the capabilities for our customers, things that had been working since the 80's break.

I found such a problem last year. Now there was a design flaw in that code, but it went uncovered for over 15 years, so it obviously "worked" (our customers were satisfied until now), it just wasn't perfect, or adequate when the system changed.

.... and it was a pain in the butt to track down.

Friday, June 06, 2003

I think Nitin just described the MSFT Windows API.  Name space pollution, buhzillionty parameters passed per function, huge switch statements, ...  Anything he missed?

Nat Ersoz
Friday, June 06, 2003

If you're developing with Java and Eclipse, you might try the plugin.  Warning, it is very compute-intensive and fairly memory-hungry.  Warning 2, I haven't actually done much with it yet so I can't claim success with it.


Friday, June 06, 2003

I asked: does the code properly perform its job? The response:

"When? Today? Tomorrow? 2 years from now after umpteen releases? Ideally the code works today (HA!), but can you build on it and still use it a  few releases later?"

Yes, precisely; XP addresses all of these things. When the code isn't working, then you should write a test cases that shows it not working, then fix it. Once it's fixed again and functional, then you're free to refactor it to simplify it (which almost always ends up with fewer bugs... code that's easy to understand is easy to verify).

Brad Wilson (
Wednesday, June 11, 2003

*  Recent Topics

*  Fog Creek Home