Oh so it’s not just me
As soon as I make more than a script, I’m using a debugger.
I really can’t wrap my head around how so many of my colleagues in the professional work field just
printwherever until they find their problem.printstatements feel like touching around in pitch darkness until I found what I sought, compared to a debugger which feels like just seeing my room and daylight while finding what I sought.I crave the challenge
^ This is the person I want to develop with. My goodness, can I produce some tasty, broken first-pass code you can go wild on.
One aspect I feel is never talked about is that setting up the debugging more often than not takes you out of the mental space of the problem you are trying to solve. A console log is basically there already in many cases.
Hmm. I, on the other hand, tend to write a lot more code than I probably should before I do debugging, so there’s plenty to go back through again.
Although this looks like it’s for a browser, and for all I know debuggers work completely differently in there.
Printing debug messages didn’t do much for me for this one time where a class was overflowing a buffer right in the constructor, and everything was fine creating an instance of it, passing it around, etc., until I actually go to use one of its methods later on in the program and it crashes. It was on an ESP32 and I had to decode the stack trace and everything to find it, took me hours because I had to learn what even to do with a stack trace.
I did both of these at once last week.
Added a breakpoint. Debugger didn’t break.
Added an
echo "here";. Debugger didn’t print.Added a
throw new Exception('fuck');. Debugger didn’t throw.Stepped through. Debugger wouldn’t let me step in.
It took me almost an hour to realize it wasn’t the debugger’s fault and that a variable I thought was guaranteed to be truthy at that point was actually falsey due to upstream changes in a spreadsheet parser. I felt kind of stupid for not trusting the debugger at that point.
Kind of unrelated, why does c sometimes fail to print if it hits a breakpoint right after a print while debugging? Or if it segfaults right after too iirc
does anything flush the buffers after the print, but before the break? otherwise, if the stream you’re printing to is buffered, you’re not necessarily gonna see any output
I don’t know, I just use printf
Im pretty sure its because of char 13 (carriage return). This char sets cursor to the start of the line overwriting whatever was printed there (in most terminals). I belive that some error messages use this char and when you print something the char at the begining or end of the error message overwrites your message. A workaround is simply printing a newline after or before your message.
Without knowing the details of C, I’ve seen this in other languages and it’s usually something with missing a flush or a buffered output mode or something like that.
“Fine! I’ll set up debugging! Stupid piece of…” - Me at some point, a little to late, into most projects
Why not both
Debug single threaded code, log multi threaded code.
“Oh, they print in that order? That’s weird.”
I miss having a functioning debugger after moving to helix/neovim
I’ve had no issue with the debuggers available in meovim. A bit hard to set up dap and dap ui but once it’s there it’s golden
I couldn’t get it working in neovim a while back and now have moved to helix which kinda has it but not really
Surely we all write unit tests and debug from there, right?
… Right?
Depending on what kind of coding you’re doing, there might not be an obvious, really atomic unit to test. Most people here seem to do the data-plumbing-for-corporations kind, though.
Especially then I’d test the shit out of everything? I’m getting paid for writing correct software.
At a certain level of detail, tests just become a debugger, right?
I’m thinking of something like an implementation of Strassen’s algorithm. It’s all arithmetic; you can’t really check for macro correctness without doing a similar kind of arithmetic yourself, which is basically just writing the same code again. It resembles nothing other than itself.
And who actually writes tests like that?
I mean, do you think tests do the calculations again? You simply have well defined input and known, static output. That’s it.
Yeah, you definitely run fixed tests on the whole thing. But when it returns indecipherable garbage, you’ve got to dive in in more detail, and at that point you’re just doing breakpoints and watchpoints and looking at walls of floating point values.
I suppose Strassen’s is recursive, so you could tackle it that way, but for other numerical-type things there is no such option.
data-plumbing-for-corporations tends to be able to be done in a way that’s easily testable, but also most people get paid to bolt on new shit onto old shit and spending time on “done” code is discouraged so once they fall behind on writing tests while developing the new shit those tests will never be written.
and bad developers that won’t write tests no matter what actually do exist.
If I actually did have that kind of job, the tests-first philosophy would sound very appealing. Actually, build the stack so you don’t have a choice - the real code should just be an instantiation of plumbing on generic variables with certain expected statistical properties. You can do that when correctly processing unpredictable but repetitive stuff is the name of the game, and I expect someone does.
Tests first is only good in theory.
Unit tests typically test rather fine grained, but coming up with the structure of the grain is 80% of the work. Often enough you end up with code that’s structured differently than initially thought, because it turns out that this one class needs to be wrapped, and this annotation doesn’t play nice with the other one when used on the same class, etc etc.
Can’t you just add the wrapper to the test as well, if it’s easy to do in the actual code?
If you have to ask “can’t you just” the answer is almost always no.
On projects where I had to write tests, I wrote them to pass the current code.
Honestly, before I’m done setting up a debugger and creating breakpoints, etc. I have added 10
consle.log()at assumed failure points and run the code again two times.For local development, it should be super quick. However, I’m currently building a small project where a device (or rather the library using it) can’t really be used with a debugger. So 500 print()s it is.
I had tried to use debugger with React so many times and each time I’d drop it soon after. Not useful at all.
Does much better job on the backend though
This meme makes it look like it’s hard decision. I always immediately slam the button on the right.
Why? In my experience using a real debugger is always the superior choice. The only time I don’t is when I can’t.
console.log(d++);Repeat.
Get to my level of guts feeling debugging
