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!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.