Premature optimization – wait, I learned that 10 years ago
In reading Refactoring: Ruby Edition, I’m “learning” a lot of things that I already know, lol.
Optimization vs. Clarity
For instance… how many times have I heard “avoid premature optimization?” Yep, check, got that one; I would never do that. Except I do! I mean, I won’t go out of my way to optimize at first. But I’m in this loop, and I want to record this other information that has nothing to do with what I’m doing right now… Let me just throw it in this temporary variable to use later.
Judges (Fowler, Beck, et al.). Buuuuzzzzzzz, wrong answer. Their advice (and you may not believe this, but I actually feel free now that it’s sunk in): don’t optimize with that temporary variable now, just code for clarity and repeat the loop as many times as it takes to get the info you need. ”Holy crap,” I thought. ”I’m not going to repeat that loop three times – that’s so inefficient!” But luckily, the authors could sense me squirming in my seat, and added that I shouldn’t worry because, although this idea frequently causes “angst” in their presentation audiences
almost all the time extra method calls won’t matter; in the rare cases they do, they can be dealt with later
This is great, Kent Beck gave me permission to repeat loops over and over if the code is cleaner!