3 ms·

> Should you really change your coding style just for better debugging? My personal answer is: not just for that, but it’s one thing to keep in the back of your

by lapcat 2y ago

> Should you really change your coding style just for better debugging? My personal answer is: not just for that, but it’s one thing to keep in the back of your mind. My personal answer is yes, absolutely. 15 years ago I wrote a blog post "Local variables are free": https://lapcatsoftware.com/blog/2009/12/19/local-variables-are-free/ https://lapcatsoftware.com/blog/2009/12/19/local-variables-a... Updated 7 years ago for Swift: https://lapcatsoftware.com/articles/local-variables-are-still-free.html https://lapcatsoftware.com/articles/local-variables-are-stil...

isx726552 2y ago
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! Edited to add: and thanks for keeping it up to date with the new Swift version!
Terr_ 2y ago
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.)
- hinkley 2y ago
  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.
spullara 2y ago
"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.
josephg 2y ago
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.
- zahlman 2y ago
  Python supports something analogous since 3.7 (https://docs.python.org/3/library/functions.html#breakpoint 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.)
hinkley 2y ago
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.
zahlman 2y ago
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.

by lapcat 2y ago

isx726552 2y ago

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! Edited to add: and thanks for keeping it up to date with the new Swift version!

Terr_ 2y ago

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.)

hinkley 2y ago
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.

spullara 2y ago

"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.

josephg 2y ago

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.

zahlman 2y ago
Python supports something analogous since 3.7 (https://docs.python.org/3/library/functions.html#breakpoint 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.)

hinkley 2y ago

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.

zahlman 2y ago

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.