Telling quality of source code from its shape

Question

This is a jigsaw piece I am maintaining (bonus: green = commented response.write used for debugging)

So I am wondering, what kind of shape do good code tend to have?

Answer 1

I think that while you might be able to find some vague shape-related patterns in good code, your time and metrics are better spent elsewhere.

(While I think the above answer should be more than sufficent, a few simple examples of this would be bad code with non-ideal layout...that could suddenly become "good" code after going through a formatter. Or consider a well written bubble sort. Nice layout, bad performance. The possibilities are endless.)

Answer 2

An interesting question. However I think that visual pattern recognition will fail for realistically sized projects. Then you may want to fall back on textual metrics, such as those provided by Source Monitor.

Answer 3

Good code is decomposed into short functions that do one thing and do it well.

Deep nesting is hard to read, hard to comprehend, and often though not always a sign that someone missed a simpler, clearer way to do something.

Code shape is telling, but more in an intuitive way than by any rule of thumb; it's something that you learn by experience, and each language has its own typical shapes .

Consider the following anti-pattern:

// code is Java

void foo( BarType b ) {
   if( b.baz() ) {
     if( b instanceof b1 ) { 
       b.mumble();
     } else if( b instanceof b2 ) {
       b.fumble();
     }
    } else {
      C c = b.getC();
      if( c.whut() ) {
        b.mumble();
      } else {
        b.fumble();
      }
    }
}

which of course we should replace with:

void foo( BarType b ) {
   b.overridenFunction();
}

Answer 4

The various repetative > > > > huge indents suggest that you need some methods to handle repetative logic.

Any time you get:

foo = bar;
if(...){
  if(...){
    if(...){
      if(...){
        if(...){
          actually doSomething();
        }
      }
    }
  }
}
baz = doOther();

it often boils down to "doStuff()" where the doStuff method can take care of all the logic, and leave the rest of the code clean and readable.

foo = bar;
doStuff();
baz = doOther();

Answer 5

Good indentation.

Line breaks where necessary. To prevent excessive horizontal scrolling.

Short methods and classes. Which tends to be correlated with good design / loose coupling.

Good use of vertical whitespace. To draw attention to section boundaries (e.g. public vs. private, preparation vs. action, etc.)

These are just rules of thumb though. Ultimately the code itself determines quality.