Developers Should Never Compromise Quality Code Ever

Blog Barista: Ian DesJardins | August 8, 2019 | Development Practices | Brew time: 4 min

Fast deadlines, desperate clients, project hangups, and personal shortcomings. As developers who put every ounce of their craft into their code, we must submit to all setbacks that make their way onto our “perfectly” paved path and navigate them with grace. Truth be told, it’s a rarity that any one of us would ever end up on a project that allowed us infinite time to craft a solution front to back that had zero cut corners, moments of contention, and nothing but the cleanest of code.

I find myself regularly laying down my ego of being “the perfect programmer” and instead choose the most pragmatic route to add as much value, and quality as I can, steadily overtime. Even at crunch time, don’t compromise on quality. Choose clean code.

You may find yourself asking what is Clean Code? It’s like a clean desk, office, or house; making it easy to locate all your important things such as your car keys, your wallet, or even your favorite hat. Clean Code is organized, highly readable, and easier to maintain by others. I’m here to point you to a handful of concepts you can keep in the forefront of your mind when you’re doing your job, all of which were extracted from the book on Clean Code by Robert C. Martin. I’ve compiled these concepts that are essential for me, however, you may build a repertoire of concepts in which you deem essential.

Name Things Really Good

The benefits of choosing good names for variables, functions, and classes moves your codebase into the direction of strong maintainability. Naming things based on what they actually represent gives a contextual representation of the execution process, and allows for what I like to call, “Visual Debugging,” which is debugging without ever having to run the code.

 DO: Give descriptive names, even if these names run a bit long.

DON’T: Skimp out on names that don’t give context where context is key.

Name Your Boolean Expressions

Writing out evaluated boolean expressions into their own variable can increase understanding of business rules tenfold and is a great example of code documentation without any extra effort. We can also use this concept to clean up raw negative conditions in an IF block, which are usually avoided. But because we are assigning the evaluated expression to a variable representation, readability does not decline.

DO: Use variables to represent complex boolean expressions. Refactor without regressing.

DON’T: Chain boolean conditionals together that represent business rules without using a variable.

Simplify Your Methods

Clear and concise functions that represent a single unit of work enables testability and makes for easier refactoring later. Keeping most functions at one level of abstraction will help with this. It’s a common misconception that if you break out a long function into many functions that are all used by one, you’re not changing anything. This is false; you’re enabling maintainability and still completing the feature at hand, while not explicitly going past a single abstraction.

DO: Break out long functions that tend to drive past that single abstraction goal. Keep the functions that you broke out in close proximity to their dependent function(s).

DON’T: Keep writing long functions without refactoring into smaller logical units.

Value Configuration Models Over Arguments

Many times you’re going to find yourself writing a high-level API that requires many pieces of data for configuration or initialization. This is an example of code that could get out of hand quickly, with too many parameters to count. This is also a great example where the use of a configuration object could be helpful. If we have a strict interface defined to construct the parameter object, we enable extensibility of our API. It’s also telling if we have a function with many parameters that cross a range of boundaries that we may need to look into #3 above and clean our codebase up a bit.

DO: Consider using configuration objects with strict interfaces for functions that require a lot of parameters.

DON’T: Write functions with a bunch of parameters that you may need to extend later.

See? It’s not too much to have just a handful of rules in your back pocket for doing your best to write the best code you can. Don’t compromise. Keep it clean. Your friends will thank you 🙂

Other recent posts: