If you’ve been a programmer for any amount of time, there’s no doubt that you once scaled Mt. Bad Code.
And things become even more complicated when it’s you or your team who’s behind it. Bad code slows projects down like nothing else and can make even the nimblest of teams halt dead in the tracks.
Bad code is an insidious issue. It breeds problem after problem, because every fix to it can break two or three other parts of the code. Every modification requires a world of understanding and a zoomed out perspective for it to become parseable.
A common analogy programmers use to describe the pain of bad code says it’s like throwing necklaces into a Zip-Loc bag, shaking them up, and then trying to separate the tangled chain links. Basically — an irretrievable mess.
In a world where time is fast replacing money as the new currency, the irreplaceable importance of clean code is more prominent than ever before.
The legendary inventor of C++ and the author of the Computer Science classic The C++ Programming Language Bjarne Stroustrup probably said it best when he said,
“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations.”
And that’s where the value of code hygiene came to the forefront. Practitioners liken the experience to the elegance of orchestral music or to a meanly designed car.
It’s coldly efficient—which in the world of code translates to speedy and productive cycles. It keeps devs from trying to go with quick fixes because the code holds no messy secrets: it’s lean, mean, and absolutely transparent.
But what goes into writing clean code?
So how can you transform bad code into clean code? Here are some actions you can take to drive things in the right direction:
Classes and objects should be noun or noun phrases like Customer or Account Avoid words like Manager, Processor, Data, Info, or using verbs in the name of a class.
A handy guide would be Naming Conventions from Uncle Bob’s Clean Code Philosophy.
Methods should be a verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is.
When constructors are overloaded, use static factory methods with names that describe the arguments. For example,
Consider enforcing this usage by making the corresponding constructors private.
Every abstract concept merits its own words. Pick it and stick with it all through. For instance, it’s confusing to have fetch, retrieve, and get as equivalent methods of different classes. How do you remember which method name goes with which class?
Sadly, you’d have to know which company, group, or individual wrote the library or class to remember which term was used. Or else you’d risk going down a winding spiral of old headers and forgotten code samples.
Boolean logic is hard enough to understand without having to see it in the context of an if or while statement.
Extract functions that explain the intent of the conditional.
Look at this example:
Well, there’s a lot going on here with too many levels of abstraction. There’s too much going on at too many different levels of abstraction. There are strange strings and odd function calls mixed in with doubly nested if statements controlled by flags.
However, with the help of simple method extractions, minor renaming, and gentle restructuring, you can transform bad code into good code.
With just a few simple method extractions, some renaming, a little restructuring, we were able to capture the intent of the function in the few lines of listing
Let’s face it: Flag arguments are ugly. Passing a boolean into a function is a terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing. It does one thing if the flag is true, and another if the flag is false!
Passing a few arguments makes a function simpler to understand and easy to write test cases.
The problem with these approaches is that they clutter the caller. The caller must check for errors immediately after the call and, unfortunately, it’s easy to forget.
To negate this, it’s better to throw an exception when you encounter an error. The calling code is cleaner and its logic isn’t obscured by error handling.
Comments maketh not bad code. And informative comments are always preferred. But commenting out your code? Well, it’s best if you avoid it.
Because anyone else who encounters your commented out code would hesitate to delete it. They would reason that it’s there for a reason and might just let it sit until it gathers like the dregs at the bottom of a cheap bottle of wine.
It’s not enough to write the code well. It needs to be maintained over time because code degradation is one of the most preventable problems out there.
So if you’re ever in doubt, think back to the Boy Scouts of America and the simple rule they stick to: Leave the campground cleaner than you found it.
That’s why experience matters when it comes to coding. Best practices have a way of ingraining themselves into developers that pay attention.
Perhaps that’s why Fortune 500s like Walmart, Nike and global pioneers like The Economist and AccuWeather trust our team of award-winning developers to deliver quality each time. Clean and custom code has a way of expressing its idea to the fullest, ensuring business owners and creators never compromise on their vision.
So if you’re ever looking to understand why clean and custom code can be your business’s biggest differentiator, reach out to us over here.
Maybe one conversation is all it takes to spark the change you’re looking for.