commandments of programming

10 Commandments of Programming

While writing codes doesn’t come with a written manual, there are a few unspoken rules that every programmer should follow. Think of them more as guidelines than rules, here are the ten commandments of programming.


1. Thou shalt name things properly

Naming things is hard, but it isn’t impossible and as long as the name of the class, method, object or variable makes sense and helps the reader to understand what is going on, then you are doing it right.

Please don’t be the person who does this:




Whilst the code itself may not be realistic, the point here is the lazy naming. It is not helpful to name something button1 or textBox3, give it a meaningful name.


2. Thou shalt not write obvious comments in the code

You shouldn’t be writing comments in your code. Code should be written to be self-explanatory without the need for comments. This commandment refers to comments like this:





Those comments are just pointless. The code’s function is obvious. However, if you really must write comments, use them to explain why you are doing something instead of saying what you are doing.


3. Thou shalt not commit secrets to open source code repositories

We all love open source software, and some of us like to contribute to them or create our repositories. You should never commit any key or secret to an open-source repository. Some people go through the commit history of public repositories looking for such things and using them for no good.

Use things like ‘AppSettingsSecrets.config’ locally that doesn’t get checked into source control. You can use environment variables and key vaults too.


4. Thou shalt not duplicate code more than once

This might sound like a contradiction, but think about what it is saying. It says you can be forgiven for duplicating some code once in the same project, but if you need to duplicate it again for another part of the project then maybe you need to refactor the code so it can exist once and be called from all of the different places which need it.


5. Thou shalt not store passwords in the clear, or with a weak hash algorithm

This one is unforgivable. No one should be storing passwords as plain text in a database, or using weak hashing algorithms such as MD5. If your data is breached, which is happens frequently these days, you want to make it as difficult as possible for hackers to access.

If they manage to get hold of your data, and you’ve done things right, they wouldn’t be able to access password and other personal data because you have a very strong encryption method like AES 256 with a different salt and vector per record.


6. Thou shalt not steal other people’s code

You need to be careful when using someone else’s code. If you copy and paste it into your program, you need to be sure that you aren’t violating any licences. You might think that you can just rename the namespace, classes and method names, but if the code still looks like the original, you can still be sued. There is a famous court case where Oracle who owns Java sued Google for copying its APIs.

There are so many different licences out there to understand, just because something is free, it doesn’t mean you can do what you want with it. The GPL licence attempts to force people to release their source code which might be a problem if you are working on proprietary software.


7. Thou shalt not take on unnecessary dependencies.

If you are a web developer, you have probably used jQuery at some point. Do you need to use jQuery any more? How much of it are you using? If it is just to get elements by their class name or id, you can do all of that with vanilla javascript.

What about dates, do you need to load in momentjs if you just want to format a date and time? The best thing to do is find out the few lines of code you need in your project to achieve these things and eliminate these dependencies unless you are using them heavily.


8. Thou shalt not write tightly coupled code

Tightly coupled code is code that can’t be tested easily. It is code which depends on other code to be able to run. It reduces flexibility and reusability of code. Test-Driven Development is a way of writing your tests first, then write your code. You only write enough code to pass the tests. You write enough tests to make sure the code fulfils the requirements.

If you are writing tightly coupled code it makes it harder to test. Following a TDD approach gets you thinking about how to write your code in such a way that it is not tightly coupled to any other code. You should use interfaces for your services and dependency injection to inject these services into where you need to use them.


9. Thou shalt not swallow errors

Let’s face it, we have all probably written a try-catch statement where the catch just swallows the error so the application doesn’t throw an error. This is bad, really bad. You should at least log the error before swallowing it.
In an ideal world, you will catch the error, log it, react to it with your code and throw it up to the next level where you can handle it appropriately there too.


10. Thou shalt not use hardcoded values

Please don’t use hardcoded values in your code. It is very annoying. If the value needs to change, what are you going to do, find and replace all occurrences of “2”?

It is much better to use constants, variables or enums instead, with a meaningful name of what that value represents and you only have to update it in one place.



Want to have your say? If you disagree or want to add any commandments, please either comment where you saw this post or tweet it with your comments and get the debate going.

Join over 3,000 visitors who are receiving our newsletter and learn about advances in technology, pick up new skills, and monetise your talent.
We hate spam. Your email address will not be sold or shared with anyone else.

Leave a Reply