Naming States

I want to talk about one of those ‘bread and butter’ topics that a developer or system designer will encounter frequently and perhaps will not think much about. Its states, or more precisely the naming of states.

If you have ever designed a table or a class to represent a transaction or any other ‘non static’ entity and plonked in a column named ‘status’ then you know what I am talking about.

Note for the Handyman Challenged: To paint a fence, you usually start by sanding it and then apply an undercoat.

The main problem I have with naming states is this.

Should the state name describe where the entity is in the process or what needs to happen next?

eg. After the fence is sanded, is the state of the fence sanded or ToBeUndercoated ?

Granted, sanded very succinctly decribes the current state of the fence, however, toBeUndercoated is much more informative. Consider a guy who does the undercoat painting. He can use the following (nice and simple) logical algorithm to find the next job to do.

Find the first fence where the Status = ToBeUndercoated

Allow me to contrast the above example with another. A line of Truck Cab & Chassis stands in the motor company holding lot. The fate or the Chassis (Winnebago, Mail Truck etc) wont be made untill an order comes in from a customer.

Does it make sense to describe the resting state of the Chassis as ToBeConvertedToAnRV? Clearly not, because we dont know yet what the chassis will be turned into. The most sensible name for the state of the chassis is FactoryComplete.

Its comes down to when you are able to make the decision about the next step in the process. If it is practicable to make the decision about the next processing step at the tail end of the last step, the ‘WhattHappensNext’ approach (ToBeUndercoated) is the most informative and sensible approach. If the decision about the next processing step is not or cannot be made untill the next step commences, then the ‘current State’ (Factory Complete) approach is the most sensible.