If your code no longer makes sense to you, do you leave it as is?

You should never remove a fence that you do not know the purpose of. The code you don't understand was not created by an idiot! And fences do not grow spontaneously. That person was solving a problem, and that problem had requirements those requirements are what this code is at least a solution for.

If you don't understand the requirements, you likely don't understand the solution and potentially the problem either. In such circumstances it is best to either not intervene, or take the time to familiarize yourself with both the problem and the solution before you attempt to intervene.

If my code no longer makes sense to me, and I wanted to change it, I would just take the time to understand it. I'm really confused that you would choose any other option.

There's an old joke about if you write code as cleverly as you are able, then you won't be clever enough to debug and maintain it.

I sometimes code out "in long' if I feel it is necessary. That is, I deliberately add extra lines to 'show my working'. As in, perhaps:

         variable = foo( bar( baz( stuff )));

might possibly be laid out as

         bazzed = baz ( stuff );   /* comment one */
         barred = bar ( bazzed );   /*comment two */
         variable = foo ( barred );   /*comment three */

to show how and why a particular result is generated, if I feel the original code is too abstruse to see quickly why it is so.

Yes, there is a (usually) negligible time cost in the running of the program that might even be fixed by an optimising compiler. But I will save a lot more time than that for myself and any other programmer in the future when maintenance time comes around.

I agree with dvorak_typist. Just recently read about Chesterton's Fence clearly applies here.

BUT this is a sign and a lesson for you to improve your documentation.

You should be able to sit down with any code you have written and understand it by reading the comments.

IMHO: Any code that is NOT documented sufficiently that you can puck it up later is "Throw away code!"

That's pretty much what I do. I'll add unit tests and do maintenance, and if possible I generally aim to rip it out completely and replace with a third party library, but I won't rewrite just because I don't understand it, unless it's causing trouble.

If I need to add features to it I'll consider it though.

I’d start by either stepping through the program (gdb, pdb, or a debugger of your choice) or adding more test cases - that’s often a quick way to understand what a piece of code is doing.

Either way I wouldn’t leave it as is, that’s just a recipe for ensuring it becomes even more opaque over time

I start making test cases until it breaks, then I rewrite it. If it doesn't break, by the time I have likely figured out how it works and I leave some comments to make it easier for the next person to understand it. Most of the time though I just try to forget that I saw it. Once I've written a comment like "there be dragons" to warn others from threading deeper.

If it provides value and doesn't need to be adapted then I'd probably leave it as is. If there are tests that I have faith in and the code is really poor I might try to touch it up if there's nothing better to do.

If your old code doesn't make sense, you better sit down, engage the code and figure it out.

Otherwise you have to concede that you're getting dumber. Someone better than you wrote code you don't understand, and it happened to be your younger self.

I would probably just sit down and figure it out, this has never happened to me but from time to time I have to think for a minute or two what something I wrote a long time ago does.

If it needs rewriting, I'll rewrite it.

If I get lost in code or something seems wrong, I comment it out and re-write the logic. I might clean it up later or just leave it in.

I'm much more comfortable rewriting code if I have good unit test coverage around it.

If you wrote it and no longer understand it, you wrote it and/or documented it wrong.

the way I see it is there are 3 things to consider. confidence in test coverage, tolerance of the client and whether we charge by the hour.