Development Tip: Avoid Ambiguity

Yesterday morning I was reviewing a database design and found myself looking at a field named status. I didn’t think much of it when I was looking at the structure because, well, it’s a status field. The field existed in a table named contract and it’s perfectly logical that contracts would have statuses, right? That’s innocuous enough. As the old saying goes, “Nothing to see here. Move along.”

I few minutes later, though, I changed my mind. After reviewing the structure of the table (when I say “the structure” I mean the output of an EXPLAIN statement), I took a look at the data and noticed that the status field contained boolean data. Now it wasn’t so innocuous to me.

In its most rudimentary form, I tend to think of most applications as a series of whats and hows. The client tells me what they want to do and my job is to figure out how to make it happen. In this case, I don’t know the ins and outs of this particular application. Sure, I understand the high level functionality and the business problems it intends to solve, but I’m not familiar with all of the hows the application employs to solve the whats.

Looking at the data, that innocuous status field became ambiguous at best and meaningless at worst. What does status = (true|false) mean? Does status mean active in this context? Deleted? Approved? I had no idea.

When building an application, it’s important for developers to be clear. Entities – variables, methods, tables, fields, etc. – should be named in such a way that someone reading the code does not need a full understanding of the application’s context or functionality in order to understand what that entity is, does or means. Code is written for the application, but should not be written solely for the application. It should be written for the application and for the developer that needs to pick it up two years from now and for the developer who works on another project, but needs to jump in to make a quick fix. Those developers should not have to wade through business logic to understand what an entity does or how it’s used.

Subscribe0 Comments on Development Tip: Avoid Ambiguity