4 ms·
If you have a statically-typed language - and it doesn't even have to be a good one, with C++ being fine, in my experience - then making such changes is usually
by to3m 14y ago
If you have a statically-typed language - and it doesn't even have to be a good one, with C++ being fine, in my experience - then making such changes is usually a case of making the change, or perhaps removing the bit of code you intend to change, compiling, and seeing what happens.
What happens is usually that you have 14,000,000 compile errors. Well, congratulations! That's the difficult part over. Now it's time to relax! Start at error 1, and fix it. Repeat. Every now and again, build. Once it builds again, it will usually work; if not, it's always something quite simple. If you have enough asserts in your code, then you can be doubly confident that there's nothing wrong with the new code.
I've had good success with this approach, for all sorts of changes, large and small. I've given up being surprised when the result just builds and runs.
I have no real idea, how you would do this reliably in a large program written in something like python. Sure, you'd fix up your tests easily enough... but then what? Don't you have a program to maintain as well? :)
Jonathan Blow wrote about this years ago: http://lerp.org/notes_4/index.html http://lerp.org/notes_4/index.html
- Evbn 14y agoIf you have 140k compile errors, you might need to factor out repeated idioms into functions.
- pkolaczk 14y ago140k is probably huge, but when talking about reafactoring, error numbers can go quite high. Refactoring is usually not just replacing a few private methods.
- to3m 14y agoErm - 140k? Actually, 14,000K! Anyway, while it was a - slight :) - exaggeration for effect, even in well-factored code small changes can have a wide-ranging repercussion.
- swalsh 14y agoIts rarely the case that you can fix 100 errors, and everything is working just 100%. There's often one corner case that works just a little bit differently.
- pkolaczk 14y agoDepends on the power of the type system. In languages with stronger / more expressive type systems than C++ (e.g. Haskell or Scala) the compiler catches really a huge amount of possible problems. The downside is it sometimes catches non-problems, too. > There's often one corner case that works just a little bit differently. You might just as well miss that one corner case in your test suite. This is the problem with tests - you can never be sure.
- to3m 14y agoIf you pick just the right thing to break, the corner cases break as well. (Sometimes you do need to temporarily break a few things in order to figure out where extra changes need making.) I'm not saying it can't go wrong when you're finished - it just usually doesn't. And it just doesn't take much effort to fix when it does.