> Debugging is hell
Most people won't care because the extent of their debugging skills is console.log, echo, print. repeat 5000 times.
Most people won't care because the extent of their debugging skills is console.log, echo, print. repeat 5000 times.
https://tedspence.com/the-art-of-printf-debugging-7d5274d6af...
While some tools/frameworks might have more robust debugging tools, if you have a dynamic role within an organization, you may not find it worth the effort to set them up if your target platform is constantly changing.
One real world example of this from my own work in PHP - there is a tool/lang-extension called XDebug that is great and provides step through debugging, but historically, it has been a pain to configure. It's gotten better, but when I can just as easily add a few `dump()` statements that expose the same data, it's overkill. Very rarely do I need to actually pause the running request to debug something and 99% of the time, I just want to know the state of that object within an specific `if()` block and a debug log gets me that same information.
After that it doesn’t matter much which tool you use to verify assumptions.
I don't agree. The first thing any developer does when starting out a project is setting up their development environment, which includes being able to debug locally. Stdout is the absolute last option on the table, used when all else fails.
while you should know this for anything you're proficient in, I usually reach for printf since it's usually quicker than messing with a debugger :)
Nothing is easier than setting a breakpoint in a line of code and running the app.
When a breakpoint is hit, you also have access to local variables and their state. Some debuggers even allow us to change variable values at runtime.
Using printf is effective, but far from being the best way to achieve anything.