So far in our discussion about what drives really good modular coding, I’ve presented override coding logic, and emphasized the importance of legibility and writing standards. I’ve found both concepts critical to my own coding for one big reason: they allow me to limit the number of assumptions I must make on the part of my users and fellow developers.
Let’s back up a bit. Every coder has some understanding of how assumptions work in programming (or at least you should; if you don’t then listen up). When we make an assumption, we are making a decision on behalf of whoever will be utilizing our work, e.g. “If A then B.” Here are some common examples…
- If a user places an order in an online store, then we assume that they want a copy of the order sent to them via e-mail.
- If a user edits an object in their profile, they expect to see some notice that their edits were applied successfully (or unsuccessfully).
- As a developer, if I use a function that is designed to output some HTML (e.g. dropdown menu), I expect that function to output the HTML fully valid, and ready to display.
As you can see, assumptions are not an innately bad thing. The whole point of any program is to perform some repeatable action on behalf of the user. At the very least we assume that the user wants to get something done. In the course of any project, you will make many assumptions, and most will be good. To put it another way, if you make zero assumptions, you’ll be staring at a blank page of “script.”
Recognizing and avoiding bad assumptions is key, and the shortest road to success is to avoid extraneous assumptions; an assumption can’t go bad on you if you don’t make it in the first place. But every assumption you do make has some associated chance of backfire, depending on a number of factors including the target audience, action being performed, code complexity, and the skill of the developer.
Now, given all that, the key here is that most coding makes assumptions for end users. They expect hand-holding, so it is typically more forgiving. However, assumptions in modular code are made for developers. If you’re a dev, tell me how much leeway do you give to code that gets in your way? Yeah, me neither.
Since your cushion for assumption-driven errors when writing code for other developers goes to zero (for all practical purposes), you obviously want to limit the number and breadth of code assumptions as much as logically possible.
Does this code really need to perform actions X, Y, and Z all together, or can I break those actions up into separate functions/classes/scripts? X and Y really belong together, so I’ll just break out Z.
When you’ve got a choice to make and it’s too close to call, that’s when you make the assumption optional (e.g. XY by default, X or Y if specified). The answer could be as simple as an extra argument in a function, or you may need to use override logic for something more complex, like a series of classes. If you weren’t sure why I considered a discussion about overrides pertinent to a series on modular code, now you know.
Just be smart. Understand who the target audience is for your code, and act accordingly. In the end, your users–whether they be the generally non-technical public, or uber-savvy devs–will use your code because it provides some exceptional form of utility (or because their boss told them to, but that’s a whole other story).
The art of assumption management is to deliver what your audience needs, not what they want. Do that every time and you’ll be a legendary coder.