"If you have nested method calls on one line of code, you can’t easily set a breakpoint in the middle."

You can now do this in Jetbrains products. Pretty awesome, you can even step through them.

Just wanted to say “thank you” for this article. I found it years ago, probably not long after you initially wrote it and have preached it as widely as possible ever since, both as an IC and as an eng manager. It’s one of the best such tidbits I’ve ever come across!

And where they aren't effectively "free", either your project doesn't need that performance or you're using the wrong language for the job. :p

(I have a lot of frustration around modern software taking a ton of CPU power to do almost nothing, but local variables aren't to blame for that.)

One of my goals for this quarter is to try to quantify the cost breakpoints of recalculation versus memoization of data, because most of my instincts are built around the tail end of 32 bit computing.@:$ while thats only a few DRAM generations ago, that’s a lot of CPU generations and thus suspect.

Nice! I’ll add that to my bag of debugging tricks. Because, It’s 2024 and conditional breakpoints still don’t fire consistently in my language / ide of choice. But this always works great:

    if i == 6 {
        println!(“xxx”); // breakpoint set here in my ide
    }

The breakpoint always fires, and unlike an assert I can run the program forward from there to see why i == 6 (or whatever) is problematic.

In JavaScript / typescript you can also just write “debugger;” in the code and it’ll break on that line when a debugger is attached. I wish more languages supported that.

Python supports something analogous since 3.7 (https://docs.python.org/3/library/functions.html#breakpoint). (Before that, you could put a breakpoint in the code using the standard library `pdb.set_trace()`, but you couldn't "detach" the debugger with an environment variable - only by monkey-patching the `set_trace` name.)

I keep hoping someone will come up with an objective way to score readability of libraries under a debugger breakpoint so I don’t have to be the one to try to do it. Data on the stack is a large part of that but far from the only factor.

Years ago, I hated having "unnecessary" local variables in my code, i.e. for things that would only be written in one place in the code, and then immediately read in a single place. What was the point, I thought, if I wasn't getting any DRY benefits from it? It just looks amateurish to force the reader to think about the code in individual steps.

But nowadays I've realized many benefits. It often simplifies dealing with line-wrapping and debugging; but more importantly, such a local variable is a name for a subexpression, and giving such a name helps document the code. Making the reader step through the code forces awareness of what the steps are and why they need to exist. And yes, naming things is one of the "hard problems", but that's not a reason to avoid it.