3 ms·
> It also makes diffs simpler to read. I find that there's a pretty direct conflict between trying to keep diffs 'pretty' and the quality of the ever-growing c
by wellpast 11y ago
> It also makes diffs simpler to read.
I find that there's a pretty direct conflict between trying to keep diffs 'pretty' and the quality of the ever-growing code.
In my experience, code quality is only achieved and sustained by continual refactoring. When this continual refactoring attempts to satisfy easy-to-read diffs the objective stops being to simplify the code itself and rather to simplify the delta -- which limits/checks the simplicity the code can achieve.
- pshc 11y agoThat's a good insight! At one point last year I found myself in the trap of playing 'delta golf', to the extent that I would leave extra {...} blocks around if it meant not having to de-dent a dozen statements. It was definitely an unnecessary self-imposed constraint that grew out of an adversity to merge conflicts.
- shoo 11y agoi think one rule of thumb to follow is to keep each diff focused. making a functional change? e.g. adding a new feature / fixing a bug? don't try to clean up neighbouring patches of code, just make the change in a way that is easy to review refactoring / cleaning up code / changing namespaces in 1000 files? don't make functional changes! trying to review a diff that has superficial changes to 1000s of files and also a few hidden surprise functional changes is a complete nightmare. note: just because the revision history should be cleanly separated like this, doesn't mean you have to work like this. you can make interleaved functional changes and refactors when you are working locally - you just need to use your version control's history editing capability to tease apart / re-order your changes and commit them separately.