It’s imperative

If you’re writing code in an imperative language like C or Python, there’s one over-arching heuristic that I think all such hackers should try to follow: don’t write whopper routines.

What are whopper routines? Well, if you don’t know, maybe you are subjecting the world to such source-code.

Whopper routines are functions, routines, methods, that run on and on, and try to do everything all right there. These routines kind of even look like a whopper (burger), as all the conditional branching is falling out everywhere, like onions and pickles hanging outside of the sandwich.

A whopper just does too much. It doesn’t share any of the logic with smaller routines that could more effectively specialize in some of the parts.

But this isn’t all about aesthetics; there’s a prime reason why one should avoid whoppers.

Unit tests

When you create whopper routines, the amount of setup needed to test such code is daunting.

Say, for instance, you have a ‘main’ Python routine that calls an external API, digests the data, converts it to something meaningful for your application, and writes to a file. To test this whopper, in a unit test, say, you’d almost need to create the world over in order to make it all work.

However, if your ‘main’ routine called a dozen-or-so smaller and more specialized routines, then it would be infinitely easier to write unit tests for these little individual functions.

You could have a unit test for the function that converts the API data (you just need to cobble together some binary/plaintext to pass into it); You could have a unit test for the little function that writes to disc, even.

With these minion routines, unit tests are a snap to write. And for imperative languages, a tested codebase is a strategy that’s wise to have when code failure isn’t an option.