Born and raised in Montana. I love drawing and technology. I lost my job in home construction due to the economic downturn. It was then that I realized I loved to code.
These rules are great, thank you for writing this. The only rule I would disagree with is 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.
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.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!