10 Coding Best Practices to Follow

Programmers hate bureaucracy and rules but when rules make things better, it is different. For instance, there are numerous coding best practices, some of which are more pain than gain but there are also many others that can make your life as a programmer much easier. Here are 10 language-independent tips that can make your coding experience much more productive. These best practices apply when you work in a team, as well as when you work on your own.

1. Always Document Your Code

I know most developers just hate it when they have to document their code and consider this a waste of time. Yes, this could be a complete waste of time, if you are not writing meaningful comments but if you do, then comments are really helpful later when you or somebody else needs to use this code again or make changes to it.

You might think documenting your code is useful only when you work in a team and other developers read your code but this isn’t so. Even when you are the only one who is working on a particular project, comments in code and other documentation are important. For instance, this isn’t hard to write but it can save you a lot of work someday.


If you don’t believe it and think that since you have written the code comments are obsolete because you know what you have been doing, just experiment how it goes with undocumented code you’ve written a couple of months or years ago. Most likely, when you open the code, it won’t look totally unfamiliar to you but just try to read it and you will see how much you have forgotten. In such cases meaningful comments can save you a lot of hassle, when later you need to revisit code written in the past.

2. Use a Version Control System

The use of a version control system is another best practice that can save not only lots of effort but sometimes even your sanity. A version control system keeps track of all the changes made to a project’s files. When a team of developers works on a project, a version control system is a must because without it you can easily overwrite each other’s changes and create a huge mess.

However, similarly to code comments, even if you work on your own on a project, you will benefit from a version control system. For instance, if you have to revert to a previous version of a file, without a version control system this would have been impossible.

Source Tree App

SourceTree: Free Git version control system with the Mercurial client for Windows or Mac.

3. Adopt an Easy to Understand Naming Convention

The way you name your functions, methods, variables, and properties matters a lot about the readability of your code. Basically, you should avoid long names (because they are harder to type and increase the risk of typos) but try to use descriptive names for your variables and everything you name.

Most programming languages have some stricter or looser naming conventions of their own, so you might want to check if there are any recommendations for the languages you use. Of course, you might not like these recommendations and you are not contractually bound to use them but no matter what naming convention you choose, always be consistent.

For instance, it’s common for developers to name functions, methods, variables, properties by capitalizing the first letter of each word or by using underscores:


Both are convenient and you can’t say one is better than the other. You are free to use either of them, just remember to be consistent.

It’s also best, if you are consistent about temporary variables as well – for instance, always use the same letter (i, j, or whatever you like) for any loop variable in your code.

4. Be Consistent in Indentation

Poor indentation won’t make your code crash but it seriously makes it more difficult to read. Because of this, it’s best to adopt an indentation rule and follow it. For instance, here are two examples with different positions of the opening bracket:

if ($something)

if ($something) {

The position of opening brackets is just one aspect of indentation. The number of spaces/tabs in the beginning of each line is another aspect. These could be open for discussions but they could also be fixed in stone by the best practices your team has adopted. However, if you are free to decide, pick the indentation convention that suits you most and stick to it.

5. Don’t Skip Planning and Testing

The planning and testing phases of the software development cycle might seem like a waste of time, or in the best case, as tasks that should be finished as quickly as possible so that we can move on to the really important tasks, such as coding. But in fact it’s just the opposite.

When you don’t plan properly, there will be a lot of code to write – mostly just rewrites of the same functionality you’ve coded multiple times since the beginning of the project. When the development process isn’t planned properly, no matter how good your code is, it will need multiple revisions because new requirements will popup all the time.

Similarly, when you skip testing, again you will have a lot of code to write but this time it will be bug fixes. Testing doesn’t have to take ages. After all, there is automated software that does the grunt work for you. It’s true that no matter how thoroughly you plan and test you can’t foresee everything. However, if you don’t at least make an effort to plan and test, then it becomes a nightmare.

Testing Anywhere

Automation Anywhere: The main screen of the Testing Anywhere app.

6. No Hard Coding

Hard coding seems very attractive because it’s much easier. However, when you hardcode file names, addresses, or anything else that is valid for a particular case only but is inapplicable to any other case, this isn’t professional because your code is not portable.


Additionally, even if you manage to run it (after you change the hard coded stuff to new hard coded stuff that applies to the present situation), maintaining this code in the future is much more difficult and many more errors are likely to happen. This is why you should always stay away from hard coding and use it only if you absolutely have to.

7. Keep Code, Data, and Layout Separate

At the turn of the century, when sites were predominantly static and CSS and PHP were still in their infancy, it was common to have data and layout code in one file. However, as sites get more powerful and more beautiful, this doesn’t work. Instead, everything that goes with layout is put in a .css. Similarly, all PHP functionality for example, goes in php files, where there is no place for pure HTML stuff. All these three – CSS, PHP, and HTML must be separate. You can have an HTML tag or two in a php file but always remember that these three must reside in separate files. The example is about HTML, CSS, and PHP because these are very common in Web development but the rule is valid for any other programming language.


The reason for this is not only that this way it’s neat. There is one more pragmatic reason, which is especially valid when you work in a team. Usually in a team there is division of labor – i.e. while a coder works on one set of files, a designer can work with the layout files only without having to coordinate and synchronize with each other. If you mix code, data, and layout in the same files, you will have to wait for one of you to finish their job and only then you can start yours. This is everything but wise, so just keep data and layout away from each other.

8. Be As Simple As Possible

Simplicity is key and programming is not an exception. The best way to perform a task is to perform it in the simplest way. This not only increases speed but also reduces the risk of errors. Well, sometimes the most difficult is to find the simplest way to do a job but always try. When your code is simple (and logical), maintaining it in the future is much easier and this is a huge payoff for all the efforts you’ve put in finding the simplest solution.

9. Code with Security in Mind

Your code might be beautiful, simple, well-documented but when it’s easy to hack, what’s the point? While there is hardly a programmer who writes insecure code on purpose, for many coders, especially beginners, security comes second. If the code compiles and runs without obvious bugs, then the job is done. This isn’t so. If the code can be hacked with ease, this is a bad job.


On the other hand, there is no need to get paranoid. No matter how thoroughly you cover your code, you can never say it’s 100 per cent unhackable. The best you can do is check what security measures are applicable for your language and follow them.

10. Cut Deep Nesting to the Minimum

In addition to poor indentation, deep nesting is another bad practice that kills code readability. While I’ve noticed that some developers are very proud of their deep nested code because it does work but nobody else except the author of the code is brilliant enough to read it, if you want to make your code better instead of using it as a tool to prove how smart you are, stay away from deep nesting.

Of course, there is no way to avoid nesting at all – even if there were, it wouldn’t be necessary but if you notice you have chunks of code with more than 3 or 4 levels of nesting, do something. You might need to rewrite your code to avoid that many levels of nesting but do it because otherwise your code is harder to maintain.

<p><i><b>Three levels of nesting are just fine!</b></i></p>

I can’t say these coding best practices are universal. Every company and team have their own best practices. For instance, if you work for a huge corporation, you probably have a much longer list of coding best practices because each of the ten items on the list comes with a separate manual of best sub-practices. Of course, it’s not quantity that matters – what’s important is that you have the best practices that work for you and that you follow them.

About the author

Ada Ivanova is a fulltime freelancer. She finally managed to find the perfect job that allows her to combine writing, design, (some) coding, and entrepreneurship skills under one umbrella.

Share this post

Leave a Comment

Subscribe To Our Newsletter