5 Coding Best Practices

By Alexander Quintero

An inevitability of being a software developer is that you must code.  An inevitability of being a good software developer is that you must learn to code…well.  A common trend among unseasoned, up-and-coming developers (and even developers with many years of experience!) is that of rushing into a project finger-first, as opposed to head-first.  This often leads to cowboy coding: coding devoid of any sort of planning and lacking any formal software developing methodologies.  If your company has an in-house software development team or employs the services of a software consulting team, it may be suffering from the effects of this gung-ho approach!  In his book, Facts and Fallacies of Software Engineering, author Robert Glass presents a guide with suggestions as how to best handle the maintenance of sloppy code.  Facts 41-43 explain that code maintenance consumes roughly 40%-80% of software costs.  It is not uncommon to hear the expression “coding is 90% maintenance and 10% development”.  However, conducting proper maintenance, even from the start, is a solution, not a problem.  Below are 5 basic coding best practices during software development that help to keep code clean and readable for a future set of eyes:

1. Naming Conventions

Following a good naming convention means using the same formatting for variable, method, and class names respectively.  This helps code to look cleaner as well as to identify any of these items more easily.  In addition, give variables, methods, and classes names that accurately describe their purpose; future developers looking at old code would rather do without wasting time guessing at the original developer’s intent.

2. Commenting

Adding comments to code is a useful way to briefly explain how a snippet of logic works, but commenting should be used sparingly.  Don’t trouble yourself with adding your name and a timestamp when modifying someone else’s code; with version control, tracking down changes between code revisions, along with who made the changes, makes these kinds of tendencies all but obsolete.  Version control also helps when a piece of logic is missing and a portion of the code needs to be reverted; in other words, delete any commented-out code clutter.  Refrain from adding too many unnecessary comments as this will also add clutter to the code.  The rule of thumb is that well-written code should be able to do without comments explaining what it does.  Finally, ensure that all TODO comments have been taken care of in the initial stages of the project.

3. Process Automation

Condense repeated functionality as often as possible!  If you notice that a chunk of logic is reused multiple times throughout a project, try to find a way to merge that logic into a centralized function that can be called multiple times throughout the code.  This helps to make code much more efficient and readable, and can also be a fun coding exercise!

4. Readability

Ensure that the code has proper formatting.  Refrain from dumping huge chunks of text into one line of code.  For example, if you are assigning a long SQL query into a string variable, break up the query into pieces and place each piece on the following line.  Also, make sure that code is properly indented and that every opening curly brace/parenthesis has a clear closing curly brace/parenthesis.  This gives the code more visibility and makes it easier to read.

5. Code Refactoring

Take the time to conduct a Quality Analysis of the code on your own or with others in order to find ways to better implement certain logic and make the code run more efficiently.  ReSharper is an excellent Microsoft Visual Studio tool that helps with this practice by conducting code inspections and automated code refactoring.

These tips and many more can help tremendously in cutting down on the time it takes to read through, understand, and maintain old code currently in production, effectively saving your company a lot of money.  If you partake in regular coding, do you follow any of these best-practice conventions?  Or if you employ the services of an experienced business/software consulting team, can you ensure that their developers do?