5 coding best practices you should cultivate from the start

We’re all familiar with the neurotic-programmer trope. Though certain programming best practices may seem to be excessive and borderline neurotic, there’s real value in producing code that is organized, modular, and understandable. If you learn to program with this objective in mind, you will become the type of programmer that companies, managers, and teammates appreciate. This wikipedia article is a good place to start cultivating your perspective and opinions on how to be an efficient and effective programmer.

Here are 5 best practices you should consider incorporating into your programming habits:

1. Learn the conventions:

In most programming languages, there is the “right” way to do things, and a “sloppy” way that isn’t the standard approach but is still accepted by the browser/command line/interpreter/compiler that executes your code. However, “sloppy” code might break when run by “stricter” compilers.

Even though “sloppy” code doesn’t always fail, it’s important to learn the proper conventions, which are style guidelines for things like:

• Naming and declaration for variables and functions (e.g., underscore notation this_is_my_var vs.camel-case notation thisIsMyVar)
• Proper use of white-space, indentation, and comments

Again, the objective in using proper convention is to make your code readable and easy to maintain. There are plenty of resources online to learn these conventions. Here are a few examples:

• Ruby style guide
• Javascript style guide (from airbnb)
• The Hitchhiker’s Guide to Python

2. Comment your code:

Comments are pieces of code that do not get executed — think of them as “breadcrumbs” for you or future users of your program to follow and understand the logic. For example, you can use comments to:

• write a header at the beginning
• specify author or date of a file
• explain what a given variable is
• describe how a function works or what it aims to do
• mark loops and remind you of what’s being iterated

Comments are immensely useful in making your code more understandable not just to other people but also to yourself. The key is to write the bare minimum of what’s useful and explicative. Harvard’s CS50 style guide suggests writing comments that address one or both of these questions:

1. What does this block do?
2. Why did I implement this block in this way?

Remember, excessive and obvious comments are pointless.

3. Clean, revise and be DRY (Don’t Repeat Yourself):

As we revisit our code, we’ll undoubtedly see opportunities to refactor. It’s always useful to go back to your code and revise so that it’s written in the best way possible. The program may have already been fully functional, but you will regret it when you later need to go back to the code, and it’s cumbersome and messy to follow.

Programmers agree that repeating the same code in multiple places is bad. Having identical (or nearly identical) code within the same program is generally a bad idea. So rather than reaching for the copy and paste keys, think about how you can leverage existing code that addresses the same objective.

4. Be modular:

Modularizing your code is a great way to be DRY. Modularity means breaking down your code into smaller components that can be executed in separate chunks which is especially useful when writing complex functions. A good question to ask yourself is if there’s a bit of logic that can exist in its own method so that each method is responsible for only one thing.

For example, it’s useful to make many smaller “helper” functions to perform individual tasks. You can then write an overarching function in which you call all the “helper” functions to execute the complete task. By breaking your code into smaller functions, it’s easier to identify, locate, and fix errors in your code. It’s also cognitively more organized to think in small, manageable “packets” of code, each of which does one specific thing.

5. Use print statements:

It’s not always easy to find bugs in your code. Fortunately, most languages have a way to “print” something to the console while the code is running which can help pinpoint the potential causes of error. For example, you can print variables at different points in your code to see if the value of the variable is what you would have expected it to be based on the manipulations that you are doing to the variable through the code. If it’s not, you did something wrong, but based on the location of the print statement, at least you know where to start looking.

Are there any other best practices that come to mind? Or, do you vehemently disagree with any of these suggestions? Feel free to share your thoughts below — we’d love to hear what they are!