This article was originally posted on Sep 9th 2018 at: https://nickjanetakis.com/blog/using-print-statements-are-a-handy-way-to-debug-and-explore-c...
For further actions, you may consider blocking this person and/or reporting abuse
I still remember once I said in reddit:
I got lots of negative attitude like:
Heck yeah... I generally use
Console.WriteLineorprintfor debugging my apps!To make finding the printed line easier for me (say I wanna see the value of x), I do something like:
So I'm gonna search for the word "koko" in the output, and the next line should be
x:DYeah I'm going to have to agree with them for the most part.
This is fine for a quick "Does it hit this line?" or "What is the value of this one thing?" But from there you need more diagnostics. What caused that value? Now that I know this value, what are the values of these other things, how many times is this gonna loop, why didn't this thing evaluate to true? You might have all of those questions sequentially, and will have to run your program again and again and AGAIN. But if you had a break point, and used your debugger, you could have figured it out in one run. You could have used the console to evaluate some operations on the variable
x + 2is"12"instead of3because x is a string, oops. Its easier to see types and things using the debugger than using print.I agree with you... in some cases like doing queries and digging through each the vars in the hierarchy, it's much faster to debug.
But, for checking the type, one simply can just
print(type(x))aside from the fact that exceptions show clearly what happened when you add two different types in python :DBut using the debugger as a frequent used tool is just time consuming.
That works in python, but for other langs it won't. In addition the debugger should not be any more time consuming than the print statement. Add the break point and run the program, you have to type the print and run the program anyways. If its too hard then you have some other problem in your workflow to work out. You also run the risk of forgotten print statements and logging. enough of those especially in a loop can absolute MURDER performance. Print statements for debugging are no faster than debugging, but they are more dangerous.
I developed recently in django and spinning the debugger takes more time than printing and re-running the app.
It always depends, sometime running the shell and trying things out there is really much faster.
When you try this stuff in Android development (esp. Xamarin Android), you will change this line :D
Generally you won't test a loop or an algorithm by hand / debugger, you would write logical tests against it... and run those tests till you get green ;)
You would love non-suspending breakpoints in the IDE, the effect is the same but you do not modify the code.
Seeing this type of posts in 2018 is staggering, but hey, if it works for you ...
I'm just spoiled because debugging was a much better experience 20 years ago with Visual Basic 6. Everything was super integrated.
Nowadays you have web servers, templating languages, databases, backends, frontends, etc.. It's not easy to find a debugging solution that doesn't completely suck, especially if you consider you're running your apps in Docker (and most editors have no idea how to debug code running inside of a container).
Over the years I found it faster (and easier) to just litter in print statements on demand where necessary. That's after building about 100 apps in a bunch of assorted frameworks and languages.
I got php remote debugging working with both phpstorm and with vscode if anyone needs help on it. It was an absolute pain in the ass. I'm here for you fam.
Yes that is true, that is an universal method, cross langauges, envs and editors. But we should make and use better tools. let's improve.
We all did this. And we know it's not too wrong, although there are better ways - like log files. But writing an article to encourage the young and misguided to use this is a whole new level of wrong. This is how sometimes debug messages slip in production and users can see them. And all modern languages and environments have excellent debug and logging tools, that are thread-safe and may work even across multiple servers.
And yes, I did this too, but I'm not proud of that I would never encourage it.
JavaScript Console has so many methods.
But I use console.table often to quickly see an object in a tabular format (as I learned how from Wes Bos).
I rarely use'em all but Wes has a course on how to print like a
Bos😉.What the actual! This is amazing!
THANK YOU!
One of the situations where logging is really invaluable is doing any kind of post-mortem analysis. If there's an event you're looking for but you need to know the state from some time before that, investigating issues in production environments, tracking down bugs with really low repro rates, etc.
I've yet to use it, but Visual Studio Code got a "logpoint" feature that caught my eye. Apparently it's also in regular VS (and probably other IDEs), but it was the first time I'd seen it.
I'm mainly a Python programmer for embedded electronics and hex files voodoo so I tend to use a lot of print statements pretty much everywhere while debugging, I used the logging module too but for a more "rock solid" debugging purpose where I expect things to fail. But for the casual quick'n dirty "why the f*** is this not doing what I want" I plague the blamed chunk of code full of prints; once I figure it out I remove them and put a more sensible logging code for next time. So far I haven't got much trouble (if any) although I'm not used to production and all my work is mainly in-house dev and precise problem solving.
I tried the debugger a few times but...since I do a lot of cross-programing (writing code in my computer and running it on a raspberry) modern debuggers are more clumsy than a straight print. I'm still learning on my own so I can only talk about my actual know-how and experience. Maybe someone can point out a better approach?
Did people really forget about this?
When in doubt, log it out.