Quick plug to write a test first, then do the refactor according to your schedule. It's such a common feeling to want to fix the code while you're refactoring it, but that's often a bad idea. Test it first, then refactor it in place (without changing the outcome), then work on fixing it later.

Well if I get the chance, I talk to the person who wrote it, to get the full picture. Because it's way to easy to judge or miss something, without getting the circumstance or understand the whole picture.

Certain things I'll always refactor like stated in the pragmatic programmer: Don't leave broken windows.

So naming or comments are getting replaced and changed on the fly all the time or logical conditions inversed to increase the readability.

I try to separate commits for that though so one is about semantics / style and there is no functionality change.

If there is a design flaw or something in the code architecture. It is something I will create a todo for and in my code there is a rule ... in the final commit there are no todos without a ticket number.

because I don't need to read my good intentions 3 years laters and it's documented for the project management to see so there is transparency outside of the codebase as well.

Also for save refactoring you need to have several levels of testing, if those tests don't exist or you have certain database lock / timeout / async changes this can escalate from personal taste of aesthetics to a complete breakdown of the production system because we like to think about or problem localized ... maybe the 'ugly code' is the fully optimized version of twelve system crashes .... which leads us to my first paragraph ... talk to the person who did it and see if you were just hasty.

But yeah in the end it really depends on a lot of different factors ....

I once was tasked to refactor a 10k+ line disorganized and effectively illegible series of Stored Procedures, much of which having originally been authored when I was nine years old (was 23 at the time). Some devs were pissed that it was practically impossible to ascertain exactly what I had done, with the left half of the diff fully red and the right half fully green. So at my day job, I try not to do that nowadays unless I really, really need to (for my own mental health and posterity's sake alike). Still doesn't go over well, especially since some of the code was written by active senior developers on the team who actually remember piecing it together over the past 16+ years.

Smaller things I'll fix up on the spot, though.

I usually try to nail down the dev responsible, and give them a strongly worded lecture on best practices.

But then it ends up being me, so...

If it's my own code in a hobby project that I'm still working on (presumably I am, otherwise I wouldn't have come across it), then I'll often refactor it immediately.

At work it's not as easy of course, since there are budgets and plans, and other people who disagree with mygenius ideas.

monkeyuser.com/2019/code-entropy pretty much summarizes this nicely 😂

I try to follow the blog.cleancoder.com/uncle-bob/2015/11/18/TheProgr… as much as possible. Styling problems can most times easily be fixed with the IDE or some tool.

Full refactoring every month? I doubt those people get anything done.

If it's just coding style I tend to leave it as it is. Coding style changes all the time. So I would end in rewriting it again in some months for no real reason.

If I have to work on it (f.e. add something, fix a bug) I refactor it.

If it is likely to take 5-10 mins of my time, I take a detour, rewrite it and then come back to what I was doing. Otherwise, I just leave a todo and try to get back to it later. :) What about you?