dark mode light mode Search Menu

How to Be a Better Programmer

Steven Depolo on Flickr

Here are my top 10 rules to follow which will enable you to become a better programmer

1. Don’t repeat yourself.

This is a great principle to follow. I really enjoy going back through my code after I have written it and refactoring parts that are used more than once. I get a buzz from reducing a long method down to several short methods. Ctrl+R+M works great in Visual Studio to help you refactor code into separate methods. This makes the code more reusable and testable.

2. Name your variables to say what they are for, not what data type they are.

For example, if you use the .NET framework class called StringBuilder to build a list of email addresses as a single string value, with each address separated by a comma, you might write code like this to create a new instance of a StringBuilder object:

StringBuilder stringBuilder = new StringBuilder();

where StringBuilder tells your .Net software to use the StringBuilder framework class, stringBuilder is your variable name that contains (equals) a new instance of a StringBuilder object with all the constructors, properties, and methods within the StringBuilder class.

However, your code is more readable and accurate if your code looks like this:

StringBuilder emailAddresses = new StringBuilder();

In this case, the confusing variable name stringBuilder has been changed to the more accurate name emailAddresses.

The only exception to this is if you are picking up someone else’s code and are continuing with that, you should carry on with their naming convention.

3. Give your methods a clear name for what they are going to do.

For example, a method called CountWidgets most likely adds up the number of widgets you pass into the method.

If you do this well, it reduces the need for comments. You shouldn’t need comments if your code is clear enough to read.

4. Don’t use magic numbers or string literals.

There shouldn’t be any numbers or string values in your code that when someone comes to read later wonders what they are. Create constants, enums or private variables to give them a name so it is easier to understand.

For example, a statement of Password.Length > 22 uses 22 as a magic number. Ideally, the statement should be password.length > MaxPasswordLength and MaxPasswordLength should be set equal to 22 as a constant. This allows MaxPasswordLength to be used in multiple places in your code with only one place to change if the value is changed in the future:

MaxPasswordLength = 22
Password.Length = MaxPasswordLength

String literals work the same way. Imagine if you have a company name in quotes in multiple places in your code. Then the company changes its name. Using a variable CompanyName instead of “Our Big Company” in quotes is much easier to change and the purpose and value of the CompanyName variable is clear to anyone reading the code.

5. Write your methods so they can be tested without having any dependencies on other parts of the application, where possible.

Write it in a way that it doesn’t matter where it was called from. It makes the code far more testable and reusable.

If you are using session values or app setting values, pass them in as variables instead and get the session and config values at the point you call the method. This makes it far more testable.

6. Don’t be afraid to ask for help.

I’m not saying you should ask for help with everything and not learn for yourself, I mean have a good go yourself, but if you are stuck ask someone for help. They may have already had this problem and know how to solve it. Also the process of telling someone about what you are doing, what you are expecting and what the problem is, can bring you to solving it yourself.

7. Follow the boy scout rule.

If you see some buggy or messy code, fix it while you are there and move on. Don’t leave it for someone else to do, but don’t rewrite the whole program either.

8. Share knowledge with others.

Don’t be selfish by keeping your knowledge to yourself. Try to create a culture of helping others. You’ll find that you will work better as a team and you can help eachother to improve. You’re not giving away knowledge and putting your job in danger if your colleagues improve. You are making yourself more valuable as you are someone who not only has the knowledge, but can also help other around them improve.

9. Don’t interrupt your colleagues whilst they are in the flow.

Think about it, when you are programming you have all of these pieces that you are putting together in your mind, like a house of cards you are carefully trying to build. If someone interrupts you to ask a question, then you lose concentration and that house of cards could easily fall down. It may take them 5 or 10 minutes to get that concentration and pieces back together in their mind, when you could have googled it or asked someone else. If you give your colleagues this respect and let them know, they will do the same for you, which in turn will make you more productive.

10. Use criticism as a positive instead of a negative.

To me, criticism is a chance for me to improve. If there is another way of doing something that I haven’t thought of then I want to know about it as it will help me to improve.

Learn More

10 golden rules for becoming a better programmer


Avoid using magic numbers and string literals in your code


Usage of magic strings/numbers


What is a magic number, and why is it bad?


Magic Numbers


String Literals


Naming Conventions


The world’s two worst variable names


.Net StringBuilder Class




Simple Programmer


Related Posts