Better Systems Maintenance with Conditions, Constants, and Domain Fields

Today I want to talk about a pet peeve of mine; the abuse of conditions, constants, and domain fields.

Let’s start with Domain Fields. The purpose of domain fields is to define a set of attributes (type, length, conditions, valid values for example) of a field. For example, Customer City and Shipping City would share similar properties and both refer to the domain #City (I name domains so they stick out) and when I compare the values, I don’t get any warning messages that the fields are not the same.

But wait! I can compare fields that don’t belong in the same domain if I want. I create a field called ‘apples’ that is three characters, and another called oranges that is also three characters and I can compare apples to oranges (see what I did there). Sure, CA 2E tells me they are not in the same domain but it won’t stop me.

This is true, so why do I want to do this? One reason I want is to make the maintenance easier in the long run. Suppose I have to change a field, to make it longer. And let’s use the example from before with customer city. I want to make all my fields that reference a city name to be 50 characters from the current of 35. If all my fields referenced a single domain, I would only need to change the domain field and the bulk of my work would be done. If I’ve got multiple domains or fields that reference a generic domain, I’m in for even more work. It could be as simple as having the fields reference the correct domain or as complex as referencing the correct domain and re-creating/referencing conditions.

For those who have used the Web Option product, domain fields allow you to attach java script code that is then available to all fields. For example, you can add data picker java script to the domain and automatically have it available on all screens.

Yes, I’m looking at this from the point of view of a perfect world and yes, there will be exceptions but it is still an ideal we should strive towards. Ask anyone who has had to look for every reference to a particular field.

This leads me to my next point, Conditions.

Conditions, easy to read names that represent a value, are a requirement with regards to status fields. Conditions make the code easier to read. Take the following example: CTL.*Cmd Key is CF14 or CTL.*Cmd Key is Work with Orders. Which would you prefer to find when you are in action diagram? We can agree that conditions are useful, so what could my issue be with them? One word, convenience.

Conditions are defined at the domain field level (see my rant earlier in the posting on domain fields). I’m going to give an example that I’m betting is in almost every single model out there. A domain field call #Yes/No, a status field of 1 character. Now I look at that and think there would only be two conditions defined (Yes = Y and No = N), and maybe something like Blank = ‘ ‘. The more likely scenario is that this field has many conditions defined (probably one for each letter and number 😊). This can be an issue when one of those not yes/no fields needs to be changed or maybe needs the value N to mean something else.

Remember the goal of a condition is to make your code easier to understand and maintain.

This brings me to my last point, constants.

Constants are a necessary evil. And like any necessary evil, it needs to be closely monitored in its use. For example, I’ve got a field I’m using as a counter and I need to increment it by one, an acceptable location to use a constant. On the other hand, I’ve got a field that, if it’s blank, I’m assigning it a particular value. This would not be an acceptable place to use a constant, because if I am using this constant in multiple places and I need to change it, I would have to revisit each reference of the field to find the constant and update it. If it was a condition I would be able to update the condition and find all the programs that reference that condition, so I can regenerate the programs.

Go forth and do it right. Now, you know a better way to use these fields.

Eamonn Foley, Developer