Category Archives: Development Process

null checking in the extreme

Posted on by
17

In Java, we’re told to check for nulls to avoid unexpected null pointer exceptions.  This can be taken too far though.  Consider the following code:

StringBuilder builder = new StringBuilder():
if ( builder != null ) {
builder.append("data");
}

When did builder have the opportunity to become null? By definition, a constructor creates an object. We just called the constructor. We know builder isn’t null. Having extra code around just invites confusion. It leaves the reader of the code wondering if they are misunderstanding something. Worse , it is a form of dead code. The if statement will never be false so it serves no purpose.

When universities teach programming, they often leave out the parts about how to make code readable and easy to maintain for others. Whether that “other” is yourself in six months or someone else, it is still professional to make the code easy to maintain.

The extra null check certainly isn’t anywhere near the worst example of unmaintainable code I’ve seen. I’ll blog more examples of this in the future.

“code sense”

Posted on by
Reply

“Clean Code” by Robert C Martin uses the phrase “code sense” when describing a developer’s relationship with clean code.  I like this phrase.  It represents the intuition that goes with looking at code.

He writes about how most people can identify messy code.  The problem comes in how to make it better.  This “code sense” lets people “see options” and “chose the best variation.”  This whole passage comes from a section subtitled “The Art of Clean Code?”.

I find it particularly interesting the comparison to art.  Especially because art is part talent and part learned.  The talent part comes from having the ideas and certain skills.  The learned part helps one know what tools are available.  A painter learns about the types of paint available.  A developer learns about refactorings.  These are all tools in the toolbox.  You still need a human to figure out when and where to use them.

—-

This week, we are hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.

“total cost of owning a mess”

Posted on by
3

When I wrote about defending the code, I described how we don’t want to meet a date at the expense of our ability to meet future dates.  This applies to future projects as well.  If we meet the production date for the first project my producing a shaky pile of code, what is going to happen to the next project using that code base.  Some things can be scheduled for refactoring between projects.  This approach also requires trust on both sides for it to actually get done.  It also only works with selected and specific types of refactorings.

I think this is similar to Robert C Martin’s discussion on the “total cost of owning a mess”.  (Also from “Clean Code”.)  I like this expression because I think it accurately reflects what happens.  Changes get harder and harder to make as does the code mess.  They also become more and more risky.  Messy code is more likely to  introduce bugs when touched.  And bugs make the total cost of ownership skyrocket.  Which leads to an unfortunate feedback loop where things spiral out of control.  So it’s our job as professionals to make sure we do not introduce a mess and encourage our teammates to do the same.

On the other hand, we often have a mess as the status quo.  It might have been inherited from the prior author of the code.  Or it might have just snuck up on us.  When this happens, we can still try to make things better.  Even if it’s a tiny bit at a time.  Or by not making things worse.  It’s so easy to say “well it’s already a mess, so I’ll just add this hack here.”  That’s how it got to be a mess in the first place!

—-

Starting in a few hours, we will be hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.