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 princip...
For further actions, you may consider blocking this person and/or reporting abuse
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!