6 Commandments for Developers

As developers, our work will often last a long time.  Much more time is spent modifying code later than is spent initially creating the code.  Starting off on a good foot sets the stage for what comes later.  Often, it becomes impossible or really difficult to change some things later.

These are some small guidelines that will pay big in the long run.

Name boolean variables in the positive

If you need a boolean variable to enable of disable something, name it in the positive.

Good

boolean gardenHoseEnabled;

if ( gardenHoseEnabled ) {

   waterGarden();

}

Bad

boolean gardenHoseDisabled

if ( ! gardenHoseDisabled ) {

   waterGarden();

}

The double negative in the if statement leads to unnecessary confusion.  Throw this into a mix of other complicated logic and it becomes just that much harder to decipher.

Expressing the variable in its negative form in an if statement is still more readable.

I can still read this pretty well:

if ( ! gardenHoseEnabled )

Always Use A Source Code Control System

Do this even if you are just playing with code for yourself.  You will thank yourself later.

Remove Obsolete Code, Don’t Comment It

If you are using a source code control system, you can always go back to your old code.  Don’t leave the old crap hanging around.

Use Natural Keys In Your Database Tables

Some people will disagree with me.  Oh well.  If you have a table that is to contain data and there is a natural primary key for the table, use that as the key.  Do not make an ID column as your key all the time.

Avoid surrogate keys as much as possible.

a)      It is a waste.

b)      Queries get more complex.

c)       You will almost always want to search by the real key. Yes you can add another index, but an index is not free.

Build What You Need At The Time

It is important to anticipate what will be needed in the future.  However, I’ve seen developers design and build components that they thought might one day be needed only to have the component never be used.  It would have been better to build something simpler then rework it later even if that meant more work over the entire life of the project.  Being efficient is only good if you can truly predict the future.  If you are wrong, then you waste time creating features that no one uses.

Think about some applications like Microsoft Word.  How many people really use all the features in that thing?  What percentage of the features do you think get really used?  I don’t have any statistics.  But I bet that it is very low.

Write A Little Documentation

I’m not saying to document every nook and cranny of what you did.  But a short one page highlight would be nice.  This is especially true if the process is complicated or the solution particularly challenging.  Give the next guy a chance to work with the code without having to walk through every line of code and needing a series of campfire stories to understand it.

If you have access to a Wiki, this is even easier.  Write the most minimal stuff you can think of in 30 mins.  Then as others have a few minutes, they can add to it.

Do Code Reviews

When doing a code review, remember that it is not YOUR code or HIS code or HER code.  It is THE code.  It is the team’s responsibility as a unit to get the best code possible.  I’ve fought with code reviewers in the past over the naming of a variable.  In retrospect, I was wrong.  Why did I fight?  I was taking it personally.  It is easy to do that.  Don’t!

Instead, see yourself as someone who has brought the code to this point.  The team is helping to bring it further along.  It is not an attack on you.  It is not a judgement on you.

These are the items I will leave you with today.  I hope it helps you create better applications.