Here are my top 10 rules to follow which will enable you to become a better programmer
-
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. -
Name your variables to say what they are for, not what data type they are
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. -
Give your methods a clear name for what they are going to do.
If you do this well, it reduces the need for comments. You shouldn't need comments if your code is clear enough to read. -
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.
Don't repeat yourself
Name your variables to say what they are for, not what data type they are
Give your methods a clear name for what they are going to do.
Don't use magic numbers or string literals
-
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. -
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. -
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. -
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. -
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. -
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.