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.