When to refactor code

Always. The development cycle should be Test, Code, Refactor, as one atomic block of work. Sarah Mei explains why this is vitally important to creating good code in her talk "Work, Play &#38; Code", I highly recommend checking it out.<p><a href="http://confreaks.com/videos/2333-mwrc2013-work-play-code" rel="nofollow">http://confreaks.com/videos/2333-mwrc2013-work-play-code</a><p>Also, if you don't have a test suite to prove your refactoring didn't change functionality, IMO you aren't refactoring, you are simply rewriting. This is the point many people miss about TDD. TDD is first and foremost about letting you refactor your code; doing TDD right gives you the best environment for writing great code. On the other hand, doing TDD wrong makes it more likely your entire code base will be very difficult to maintain.

100 lines, hah....<p>Anyway, I don't think you need a big, complicated checklist like this. Writing code by checklist is not going to solve your problems. The more important questions are these:<p>- Do you find yourself spending more time than you think you should making changes and additions (or bug fixes) to the same sections of code?<p>- Do you often run into difficulty figuring out or remembering what a given section of code does?<p>If either of those things are true then refactoring might be a good idea. Use extract method until it hurts. Use extract method on complicated logic tests as well. Figure out where the control flow is wonky and switch to using flow based on method calls and returns to simplify things. Be ruthless. Don't be lulled into the "meaty method" trap, don't be afraid of short methods, even if they're only one line. Make your code so that it looks almost <i>too</i> simple, as though even a novice could look at it and tell you what it does. Push until you get to a state where making changes seems almost like cheating because it's so easy. That's when you know you're in the sweet spot. Programming is about making things easier, even future programming, not about proving how incredibly skilled you are at maintaining complex code.

I have a 1134 line function with zero tests defined for it sitting open in the background which most likely scores something like 32 out of 11 on that list. I'm afraid of touching that monster...

<p><pre><code> &#62; "this 10 item checklist." &#62; 11 items in the checklist </code></pre> Heh, it's not often you see an off-by-one error in prose!

<i>You probably just want to rename variables because you don't like the previous developer's naming convention</i><p>If the last developer named his or her variables along the lines of 'a', 'b', 'c', you're damn right I have an issue with their naming convention and I'm going to fix it.

&#62; Did you completely understand what cyclomatic complexity was without following that link?<p>Seems confusing that answering "No" to this (meaning you did NOT know what cyclomatic complexity was) would be a net positive for refactoring?

This seems like a checklist for when to factor, not when to refactor; he appears to be describing massive mutant code that has never actually been split into manageable chunks.