When management says “don’t refactor now” and you see this

While coding we meet sometimes one of our deamons: should I refactor what I see? The dilemma: develop as it is or “rewrite” it?

A short story of one small refactor

Dilemmas, of course, yeah. Let’s just make it working!

Let’s look at this snippet:

It stood untouched for some longer time in there. And then another developer adds this:

I couldn’t resist to rewrite all of that by actually understanding what it does.

What have I changed? It’s shorter and some variables are introduced / changed.

Asking about the language? ActionScript 3.

Refactor and afterthoughts

Comparing the previous and “better” version it may look like – hey, yeah, code is shorter but now we can’t see logical paths at first look.

However, after deep insight you’ll notice this fact: previous snippet had 4 cases where 2 were rather virtual. In reality, it happened to have only two different cases which were easy and quite readable to be rewritten as one logical condition:

If you would be interested making those cases independent then why not:

But how do you feel now? Do you expect cooldown  to be calculated differently in some longer time?

If not, then why not doing another trick?

Notice the !=  in place of == . It may look as a stupid trick. But note the fact – two first conditions (those  !=  IFs) are splitted and cooldown  calculation is written only in one place. In case of changing only one case you would probably remove the “else” part.

Much more cases?

Your first think may be “use switch”. But what would you change that way?

Instead, let’s try inverting checks:

Or if your code is really as simple as this above, you could indeed introduce a  switch expression.

Sometimes just looking at code in an inverted way than it is written helps to keep it more clean and less buggy when another person develops it more in a hurry.


My message here is only this – developers, look at and look into code of your fellows! You are as responsible for old production code snippets as the authors.