I was told the other day by a Principal Engineer (PE) to change a class I wrote and I didn’t agree with his reasoning. This wasn’t a hill to die on by any means and when in Rome you do as the Romans do. I respect this PE very much so I had a bit of a back and forth with him, but I made the change regardless. However, I will write about it here :D.
Context
I produced a class that contained well known keys and values. For the code’s purposes, they were actually called “Code” and “Description”, but these are still keys and values as far as I am concerned.
My bias
I always use integers for keys and codes when allowed. My reasoning includes the following:
- When using integers you no longer have to worry about case sensitivity, blanks or nulls.
- Integers are essentially meaningless identifiers, so if you need to adjust a description you can without having the remorse of your integer not match a theme of some kind. It’s just a number!
- The only downside to using integers is you may have to look up their meaning on occasion to remember what they mean.
The PE’s bias
The PE’s bias is to use strings for keys and codes. Their reasoning is:
- It’s easier to understand because it’s more human readable.
- The downsides include but are not limited to:
- You may have to look up their meaning on occasion to remember what they mean.
- Strings have case sensitivity by default, can be blank, whitespace or null.
- Single character strings should be meaningless identifiers, but if you wanted it to have meaning and then you need to adjust a description you may have remorse if your single character does not match your original theme anymore.
Why I think the PE is wrong
I think we can agree at this point, this is mostly subjective which is why I am calling out my opinion as bias.
I think the PE is wrong because “easier to understand” is subjective. I am a human (I think?) and I find it easier to read numbers than I do letters. So that justification just fell apart. I find both single letters and numbers just as meaningless. However, the problem with using strings is then case sensitivity, blank, white space and null are a worry when you use them. The biggest problem in my opinion is if you were aiming to have a theme in your single character codes to match their description, how annoying will be if the description changes, but you can no longer change the code?
Example of initial tables
The left table is my bias and the right table is the PE’s bias. This is the first state, where both options are totally viable at design time. This means we haven’t deployed to production yet.
| Key | Value |
|---|---|
| 1 | Dog |
| 2 | Cat |
| 3 | Goat |
| Key | Value |
|---|---|
| D | Dog |
| C | Cat |
| G | Goat |
Example of when requirements change two months after prod deploy
The left table is my bias and the right table is the PE’s bias. This is the state when your Business Analyst, Project Manager or Product Owner tells you that they got the animals wrong and have provided with you a new list of animals to use. The problem is this information has already been pushed to production and has been in circulation for two months. All of your code is wired up to use these values.
| Key | Value |
|---|---|
| 1 | Wolf |
| 2 | Lion |
| 3 | Ram |
| Key | Value |
|---|---|
| D | Wolf |
| C | Lion |
| G | Ram |
In the PE’s case, you could retrofit everything, but there is no time for that! It goes on the backlog right? It’s just more technical debt someone will get to later because this isn’t technically a breaking change, it’s just confusing to the coders.
Conclusion
I obviously have a strong opinion about this, however I have had the professional experiences to back up my opinion. It’s not baseless and it’s especially not concerned with how things look. This exact scenario has happened to me before and I want to avoid repeating a glaringly obvious mistake. Use numbers for keys and codes people! Unless the PE you respect tells you to do other wise – even if he is obviously wrong! Just make sure to file the decision away in your “I told you so” folder for later.