I'm working a small-to-medium legacy codebase and when working on a ticket I will come across code that should be cleaned-up or that I need to clean-up just to be able to understand the follow of the application.
A real example is:
if( !a && b ){
doSomething1();
doSomething2();
doSomething3();
doSomething4();
doSomething5();
}else if( a ){
doSomething1();
doSomething2();
doSomething3();
doSomething4();
doSomething5();
}else if( !b && ( a || c ) ){
doSomething1();
doSomething2();
doSomething3();
doSomething4();
doSomething5();
}
Another is fixing typos and Engrish in comments and documentation across a dozen source files.
However, often this clean-up ends up not related to the main issue and I wonder how is it best to commit the clean-up. The way I see it, there are three options:
- Before the fix: this works chronologically since this is the order in which they occur but if they break something they complicate the fix and it makes it harder to diff the fix with what was in production. It also introduces an additional commit which is noise.
- With the fix: but that obscures the actual replacement of defective code with files where
findGeoragphy
was correct tofindGeography
. - After the fix: this requires removing and clean-up you made that helped you understand the code and then retesting the fix, committing the fix, and then going back and redoing the clean-up. This allows the cleanest diff to the defective code, but duplicates effort and can lead to spurious commits as well.
tl;dr: So, what is the best method of committing clean-up code?
Context: We have no unit-tests and development proceeds by running changes and eye-balling them and throwing them over the wall to QA to validate through manual regression fixes. Also, if we don't do some form clean-ups the code becomes unintelligible. I know this is far from ideal, but this is real enterprise dev that puts food on my table and not my choice.