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
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.
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.
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.
Top comments (11)
Code left out seldom goes wrong.
I'd like to add:
These rules are great, thank you for writing this. The only rule I would disagree with is 7:
With issue tracking, such as Team Foundation Server, changes to code that are associated with an unrelated task, issue, or bug can be very frustrating and may actually break the build when it comes time to include changesets in a build.
This has been my experience at any rate. Your mileage may vary.
Agree with you, Lyon 😊
If I found the messy code during some feature implementation cycle I prefer to just somehow notice such places and do some refactorings after. I do them as separate commits, or, moreover, as a separate pull request. I do not let such refactorings to be inadvertently interconnected with the feature changes. This gives to me a clear context what I've refactored and the ability to even revert the changes as the single thing if it broke something.
Nevertheless, this list of rules is great and useful!
Good rules to code by.
There's just one rule that I feel should be less absolute: String literals. When a string appears only once (e.g. a log message or the name of a config option or so) using literals can actually improve readability without sacrificing anything. At least that's been my experience.
Give your methods a clear name for what they are going to do
I would put it “give your methods honest names for what they are doing”
even if this name will have “and” in it
like validateAndFormat()
this is the best todo hint for others (including future you) to split it.
I’ve seen so many method names like do() process() handle() doAction() and on half of occasions its because developer came up with a method too long and was confused by himself, how to name it. Probably trying to follow a rule that method name should be short, and its not possible to give a short name to something that has 500 LOC, such generic names are born. Really, it would be better to have a 128 chars long name, so that someone else could help )
Great list, these are so much more important than what language you're using or whether you space or tab!
Why would you use spaces?
For ultimate precision!... or because the labguage's style guide suggests it.
:) I should have put :sarcastic: at the end of my comment. Totally agree with following language style guides (or team’s rules around formatting)
So true. Thanks for sharing!