Three Tips for Cleaner Code

We all have written code that we later look back at and cringe. Sometimes you’re in a hurry, working too late into the night against the hours and your standards begin to slip. Or if you’re new to a language or a framework, you may not know the best patterns and stumble your way into a spaghetti-like monstrosity. Whatever the cause, we have all been there. There’s a lot of things that can be done to keep your code under control. I’ll just touch on a few of them here.

Consistent Indentation
Whether you prefer tabs or spaces, the key to keeping your code clean is to keep it consistent. Indentation gets out of control when tabs and spaces are mixed. This leads to code which is nearly impossible to follow because blocks no longer line up properly. It’s easy enough to avoid; pick the method you prefer and stick with it. Make this standard clear with your team and enforce it. If you do choose spaces, make sure that everyone is on a common standard. If you go with tabs, everyone can choose their own tab size but nobody can choose to interpret the tab as multiple space characters or things will again turn into a mess.

Consistent Naming
It doesn’t matter if you prefer camelCaseNaming or underscore_naming of variables and functions. Just keep it consistent throughout your code. It’s even acceptable to use one for variables and another for function names. Again, as long as the distinction is consistent. When making a choice, think about what’s the standard for the language you’re writing in, and if at all possible, stick ot the standard. This will make it easier for future people who inherit your code (including yourself), to understand it on first reading.

Descriptive Naming
Minimizers are a common and useful tool, but the code they output is usually hard to follow. The biggest reason being the variable names are all one meaningless letter. When choosing your own variable and method names, err on the side of verbosity. It’s a lot easier to understand exactly what getAccountTransactions() is going to do on first glance than getActTrans(). The latter may be discernible in context, but it might not be. Maybe it’s for an auto parts or communication application and Transmissions are a thing. There’s essentially no extra cost to the longer name, since you should hopefully be using an editor with auto-completion available, and your code can be minized for production if overall length of the source becomes an issue.

There’s virtually no limit to the number of best practices one can adopt to improve the quality of their code output. This is a topic where no matter how experienced you are, there’s always room for improvement. It’s also an area where any investment of effort is repaid many times when you have to go back and deal with your own code long after you wrote it.