As you’re typing away at your keyboard, creating new objects and methods, you realize something.

“Hey, what if this object is actually null?”

And so, you decide to cleverly check if the object is null, like so :

public void doStuff(Object object){
  if(object != null){
    //Work your magic on this object
  }
}

However, there are several problems with this approach. For instance, most programmers who use this technique do nothing if the object is null. This causes huge amounts of bugs and headaches for everyone.

In addition, null checking an object everywhere causes excessive bloating. In fact, most of these checks are unnecessary. You should not be checking if an object is null inside the main parts of your code. It is best to only check when data is first passed in.

An analogy for this is as follows :

A city, known for its wealth and prosperity, lies in the middle of a desert. Every one in the city is confirmed to be a good citizen, and crime rates are at an all-time low 0%. However, one day, a group of vandals approach the city. As they reach the outskirts, they are caught and kicked out. No criminals allowed!

The city continues to prosper for the rest of eternity.

However, a few dozen miles away, another city named Nullville exists. Unlike the other city, Nullville has no guards around the city. As a result, the city is flooded with nasty and evil people. To combat these evil-doers, Nullville decides to enforce a strict system of identification, with all good people getting an ID.

If you want to go outside, you need to show your ID. If you want to buy meat, you need to show your ID. If you want to go home, you need to show your ID. If you want to sleep, you need to show your ID. If you are caught without an ID, you are booted from Nullville, as you’re proven to be evil.

Clearly, Nullville is in a terrible situation. In order to do anything in Nullville, you first have to actually prove that you have an ID (proving that you’re != null). Even if you aren’t serial killer or a thief, you still have to prove that you have an ID.

As a result, like Nullville, programmers end up excessively checking their data for nulls, when it simply isn’t necessary. As in the first city, data should be checked on the outskirts of your code, not inside the main parts of it.

If you force functions on the “outskirts” of your code base to check for nulls, then you do not have to check for nulls in the core sections. The output is already guaranteed to not be null, so there is no reason, in the input of another function, to check for null.

In a nutshell, a contract needs to be made. Function A promises to return an object, but it isn’t null. Function B accepts an object, but trusts function A that the object will not be null. As a result, there is no reason for function B to check its input for null.

So don’t bloat your code. Check for nulls at the gates of your code, so that you don’t have to do it inside the code.

Exceptions are a fundamental part of a program. For example, if you creating, editing, and closing a database, an exception is needed in case anything goes wrong. However, exception handling can go awry when the exception is swallowed.

Consider the following snippet :

try{
    db.open()
    db.modifySomething();
    db.close();
}
catch(Exception ex) {
   //exception is swallowed
}

If the database throws an exception anytime between opening the database, and closing the database, then the database will simply not close. This can cause huge problems over time, as dozens of unclosed databases would exist at the same time.

The goal of exceptions isn’t to make your life more difficult. The goal is to help you, the programmer, catch errors in your code, and to give you a stack trace so that you know where your code has a problem.

Consider this scenario :

A car drives down a road, but the engine catches on fire. The man inside the car, instead of getting out, opts to continue driving and dies after the car explodes.

Or, the more logical scenario :

A car drives down a road, but the engine catches on fire. The man realizes this, so he gets out of the car immediately. He sees there is a gas leak. The car explodes, but the man survives.

The first scenario is a prime example of what would happen if the exception was swallowed. Not only does the man not know why the engine caught on fire, but he also died.

However, the second scenario shows what would happen if the exception was handled. First, the man escaped safely from the car. In addition he also knows why the engine caught on fire. Similarly, a programmer who properly handles exceptions can find out where the program went wrong, as well as why it went wrong.

Here’s a general rule of thumb :
Fail fast, fix it fast.

Every time I see an arbitrary one letter variable name, or a shortened word that could mean two things, my soul dies a little inside. Although, this problem also applies for classes (though, anyone who makes a one-letter class name is truly evil). Of course, this holds true on the other side of the spectrum as well. (see Spring’s SimpleBeanFactoryAwareAspectInstanceFactory).

But nonetheless, the focus of this post will revolve around programmers who use vague and terrible variable names.

Consider this following example :

public class dummyClass {

  public void mysteryMethod(Riders[] r){
    Plane p = new Plane();
    List<Riders> ratp = new ArrayList<Riders>();
    FlightAttendant afc = new FlightAttendant(plane);
    FlightAttendant afp = new FlightAttendant(plane);

    for(Rider a : r){
      p.add(a);
      if(a.isAllergic()){ 
        afc.add(a)
      }else{
        afp.add(a);
      }
    }

    afc.handOutCandy();
    afp.handOutPeanuts();

    p.takeOff();
  }
}

Although it isn’t clear, here are what each of the variables are :

afc is short for “attendant for candy”
afp is short for “attendant for peanuts”
p is short for “plane”
r is short for “rider”
ratp is short for “riders allergic to peanuts”.

However, the author of this code couldn’t be bothered to write out the full word because “it’s inconvenient”.
Even if you knew what those acronyms stood for, deciphering the code would still be difficult.

Now let’s rewrite that snippet in a more obvious and clean way.

public class dummyClass {

  public void mysteryMethod(Riders[] riders){
    Plane plane = new Plane();
    List<Riders> ridersAllergicToPeanuts = new ArrayList<Riders>();
    FlightAttendant attendanatForCandy = new FlightAttendant(plane);
    FlightAttendant attendantForPeanuts = new FlightAttendant(plane);

    for(Rider rider : riders){
      plane.add(rider);
      if(rider.isAllergic()){
        attendantForCandy.add(rider)
      }else{
        attendantForPeanuts.add(rider);
      }
    }

    attendantForCandy.handOutCandy();
    attendantForPeanuts.handOutPeanuts();

    plane.takeOff();
  }
}

Comprehension in this revised code is much higher, and it requires no outside knowledge. You didn’t need to know any acronyms, and you could have easily figured out the intent of the code in one read-through.

Although longer variable names means more typing, it also means higher readability. It may be annoying to do at first, but in the long run, code with high readability becomes easy to understand and debug.

While it is true that you could write code much faster if you just use single lettered variable names, or obscure variable names, your code becomes unpleasant and painful to read. So please, do your fellow programmers a favor. Stop using terrible variable names.

State based programming is the use of “states” to control the flow of your program. For example, in the case of an elevator, it could be moving up, moving down, stopping, closing the doors, and opening the doors. Each of these are considered a state, and what happens next is determined by the elevator’s current state.

For instance, if the elevator has just closed its doors, what are the possibilities that can happen next? It can either move up, or move down. You wouldn’t expect the elevator to stop after closing its doors. Similarly, when an elevator stops, you expect the next action to be the doors opening.

To apply this in programming, you can store its “state” in an enumerator.

public enum ElevatorState {
    OPEN, CLOSED, MOVING_UP, MOVING_DOWN, STOP
}

Now, you can simply check for the current state and dictate what will happen next, based on that state.

public class Elevator
{
    ElevatorState currentState;
    
    public Elevator(){
        currentState = ElevatorState.CLOSED;
    }

    public void changeState(){

        if(currentState == ElevatorState.OPEN){
            currentState = ElevatorState.CLOSED;
            closeDoors();
        }

        if(currentState == ElevatorState.CLOSED 
           && upButtonIsPressed()){
            currentState = ElevatorState.MOVING_UP;
            moveElevatorUp();
        }
 
        if(currentState == ElevatorState.CLOSED 
           && downButtonIsPressed()){
            currentState = ElevatorState.MOVING_DOWN;
            moveElevatorDown();
        }

        if((currentState == ElevatorState.MOVING_UP
           || currentState == ElevatorState.MOVING_DOWN)
           && reachedDestination()){
            currentState = ElevatorState.STOP;
            stopElevator();
        }

        if(currentState == ElevatorState.STOP){
            currentState = ElevatorState.OPEN;
            openDoors();
        }
    }
}

Of course, this is a very simple example. You would need an event handler for when you would call changeState(), or it wouldn’t work properly. But the idea is still there. You start with a state, and continuously change states over and over again. All logic/functionality depends on what your system’s current state is in.