To me logging combined with a quick compilation has a good flow to it. Causes you to consider what you want to see and doesn't change the workflow if multiple stacks are involved.
As someone who knows how to use a debugger, I can say for sure that log debugging is fine and often my first approach. If you have a good mental model of the code and the issue, it's usually just 1-2 logs to solve the problem.
It drives me crazy that half my coworkers do this, including a senior dev. I'll be on a call trying to help debug something and it makes it so difficult not being able to set a breakpoint
and the one that keeps getting slept on for some reason, watch breakpoints - stop when foo is changed. Great for figuring out what is screwing with your data when foo mysteriously changes
I used to do debuggers until I started doing embedded and dipped my feet in multithreading (2 different projects). After many hours lost because the debugger straight lied to me about which line of code has been executed, a colleague suggested that I just do a printf like a filthy beginner. And 🤩it worked🤩 and I never went back to the unreliable world of debuggers. Even though now I'm mostly working with single-threaded python scripts.
There are literally university courses which confidently state "Console logging is far more used and better so we won't talk about a debugger here"!
Like sure, it's very likely to be used far more, but that doesn't mean you shouldn't at least offer some courses or modules about proper use of a debugger...
God, I wish. I'd throw money at whoever could implement such a thing. I guess its actually theoretically possible if you just sort of wrote the whole stack to an HDD but the amount of space that would take up lol.
But yeah, good logging (and not excessive logging!) is also extremely important
Be careful, the actual logging can happen at a later time, and because the log function may take a reference to the value, if you modify r it may show the modified version of r in the logging instead of the original r.
Honestly I use debugger when I have to go deep into some library's bullshit code. My stuff should be stable clean and understandable enough to quickly see what's happening with console log.
If I were to find myself needing debugger all the time with breakpoints and all this shit, it means shits has gone sideways and we need to back up and re-evaluate the code.
I am guilty of this but for a different reason: setting up debugging for clis in rust is hard
I love the debugger. I use it all the time I can. But when debugging cli it's a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn't find cargo when it's the PATH... again, then actually debug.
I don't feel at all guilty of doing this. Whatever works. Usually nothing is so complicated that I need to debug properly, instead of just inspecting some value along the way.
In fact, if it gets the bug resolved, it is—effectively—debugging.
42 Comments
2deck@lemmy.world · 37 pts · 340d
To me logging combined with a quick compilation has a good flow to it. Causes you to consider what you want to see and doesn't change the workflow if multiple stacks are involved.
falseWhite@programming.dev · 36 pts · 340d
TurtleTourParty@midwest.social · 43 pts · 340d
Except when adding the log fixes the race condition.
Naich@lemmings.world · 22 pts · 340d
Yay! Problem solved. 🤓👍
pinball_wizard@lemmy.zip · 6 pts · 340d
(ノ｀Д´)ノ彡┻━┻
PenguinOfWar@lemmy.world · 4 pts · 340d
I see you’ve used Knex.
iAvicenna@lemmy.world · 23 pts · 340d
printf("here")printf("here1")printf("here2")
silasmariner@programming.dev · 9 pts · 340d
This is the way Although I also like:
File 1:
print(0.1)
print(0.2)
File 2:
print(1.1)
print(1.2)
..
Minimal c+p+e effort
humorlessrepost@lemmy.world · 6 pts · 339d
Too hard to find in a busy log.
console.log(‘===== here1’)
iAvicenna@lemmy.world · 2 pts · 339d
have been there though I first try
printf("HERE1")
AwesomeLowlander@sh.itjust.works · 19 pts · 340d
Can somebody reupload the image at a non-feddit.org host? Feddit is incredibly annoying in that it geoblocks most of Asia.
QuazarOmega@lemy.lol · 23 pts · 340d
There you go
fibojoly@sh.itjust.works · 2 pts · 331d
Seems to be blocking me too, in France.
vala@lemmy.dbzer0.com · 16 pts · 340d
As someone who knows how to use a debugger, I can say for sure that log debugging is fine and often my first approach. If you have a good mental model of the code and the issue, it's usually just 1-2 logs to solve the problem.
Shanmugha@lemmy.world · 14 pts · 340d
I never felt a need to do it some other way
NotSteve_@piefed.ca · 10 pts · 340d
It drives me crazy that half my coworkers do this, including a senior dev. I'll be on a call trying to help debug something and it makes it so difficult not being able to set a breakpoint
andyburke@fedia.io · 33 pts · 340d
I console.dir and debugger; and breakpoint all day. You are allowed to mix your strategies.
null_dot@lemmy.dbzer0.com · 25 pts · 340d
console for quick and dirty understanding but inspector for more complex fixes.
marlowe221@lemmy.world · 9 pts · 340d
This right here. Time and place for both.
Omgpwnies@lemmy.world · 3 pts · 340d
and the one that keeps getting slept on for some reason, watch breakpoints - stop when
foois changed. Great for figuring out what is screwing with your data whenfoomysteriously changesRheumatoidArthritis@mander.xyz · 7 pts · 340d
I used to do debuggers until I started doing embedded and dipped my feet in multithreading (2 different projects). After many hours lost because the debugger straight lied to me about which line of code has been executed, a colleague suggested that I just do a printf like a filthy beginner. And 🤩it worked🤩 and I never went back to the unreliable world of debuggers. Even though now I'm mostly working with single-threaded python scripts.
Quantenteilchen@discuss.tchncs.de · 4 pts · 340d
There are literally university courses which confidently state "Console logging is far more used and better so we won't talk about a debugger here"!
Like sure, it's very likely to be used far more, but that doesn't mean you shouldn't at least offer some courses or modules about proper use of a debugger...
Trail@lemmy.world · 3 pts · 340d
Can you set a breakpoint in production two days ago to debug an incident, though?
NotSteve_@piefed.ca · 2 pts · 340d
God, I wish. I'd throw money at whoever could implement such a thing. I guess its actually theoretically possible if you just sort of wrote the whole stack to an HDD but the amount of space that would take up lol.
But yeah, good logging (and not excessive logging!) is also extremely important
ozymandias117@lemmy.world · 2 pts · 340d
https://github.com/rr-debugger/rr
NotSteve_@piefed.ca · 2 pts · 340d
Oh this is beautiful
monkeyslikebananas2@lemmy.world · 10 pts · 340d
Meh
alert(“here”);is bettervictorz@lemmy.world · 1 pts · 339d
Not sure why you would say that. An alert() does not show you where in the code the alert was called from. A console log would show you.
monkeyslikebananas2@lemmy.world · 1 pts · 339d
There was a time when there was no console.log in javascript. Oh and browsers didn’t even have developer tools.
victorz@lemmy.world · 1 pts · 339d
I remember those days. My comment still stands, I don't know how your new reply explains why alert() is better in any way, shape or form. 😅
monkeyslikebananas2@lemmy.world · 1 pts · 339d
Oh, it’s a joke with a touch of irony. Maybe even sprinkle some sarcasm in too.
victorz@lemmy.world · 1 pts · 339d
Gotcha. It wasn't clear to me but fair enough 👍
Supervisor194@lemmy.world · 8 pts · 340d
Old school. Also the flip side:
sudo tail -f /<path to server>/error.logdarvit@lemmy.darvit.nl · 2 pts · 338d
Using -F with tail is even better than -f because it handles files getting truncated or getting created.
Knock_Knock_Lemmy_In@lemmy.world · 7 pts · 340d
I don't use the debugger. I just write perfect code.
/s
DrDystopia@lemy.lol · 5 pts · 340d
It's like the real life kraken, I've never seen it but the name causes dread.
kubica@fedia.io · 20 pts · 340d
This is what peak performance looks like:
hotdogcharmer@lemmy.zip · 4 pts · 340d
Hey how'd you get your hands on my code
darvit@lemmy.darvit.nl · 2 pts · 338d
Be careful, the actual logging can happen at a later time, and because the log function may take a reference to the value, if you modify r it may show the modified version of r in the logging instead of the original r.
oplkill@lemmy.world · 5 pts · 340d
goatinspace@feddit.org · 4 pts · 340d
madcaesar@lemmy.world · 3 pts · 340d
Honestly I use debugger when I have to go deep into some library's bullshit code. My stuff should be stable clean and understandable enough to quickly see what's happening with console log.
If I were to find myself needing debugger all the time with breakpoints and all this shit, it means shits has gone sideways and we need to back up and re-evaluate the code.
RustyNova@lemmy.world · 2 pts · 340d
I am guilty of this but for a different reason: setting up debugging for clis in rust is hard
I love the debugger. I use it all the time I can. But when debugging cli it's a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn't find cargo when it's the PATH... again, then actually debug.
victorz@lemmy.world · 2 pts · 339d
I don't feel at all guilty of doing this. Whatever works. Usually nothing is so complicated that I need to debug properly, instead of just inspecting some value along the way.
In fact, if it gets the bug resolved, it is—effectively—debugging.
solomonschuler@lemmy.zip · 1 pts · 313d