Why is "print" debugging frowned upon?

>>57143056
It's not, really. However, if that's the ONLY way you're able to debug, then you should kill yourself.

It alters the source code, thereby changing the program's semantics

It's fine for smaller projects when you know what variables are messing up.

Say you have a variable that should be equal to X, but at the end it's equal to Y, so print debugging at each step where that variable changes is fine, considering you have a small project.

If it's a larger project or not your own project, then >>57143078 is correct. It'd be tedious to do that if it's not your own, and it'd be absolute hell if you had tons of different variables and function/method calls that change the expected output.

>>57143056

It's only frowned upon by people who don't see the relationship to scaffolding used when constructing a building.

>>57143098
I agree with this, however print debugging can be useful in certain situations even on larger projects. You should optimally have a logging framework set up that will store all console output in a log file. Split things up by debug, info, warning, error, etc. This can be used for general diagnostics.

It's fine to print out some random variable when fixing a bug locally, but that should not end up in source control unless it's something that needs to be monitored.

>>57143056
It is not.

printf is a best debugger. A BEST

Because geedeebee is scary.

>>57143056
>"print" debugging frowned upon

Who said that and how are they debugging ? I fucking hate breakpoints you dont even understand.

>>57143056
reminded me of an old Google talk with Niklaus Wirth talking about debugging programs circa 1960 and inserting commands to ring a bell (the equivalent of "print") and debugging punch card programs
https://www.youtube.com/watch?v=8W5Jd_wzB90

>>57143056
>"print" debugging frowned upon?
says who? any who says this is a tard...

>>57143056
generally you want trace or debug level logging for that

>>57143056
Because in C, any undefined behaviour can cause the program to crash *before* execution gets to the point corresponding to the source where the undefined behaviour would happen, thus rendering printf debugging useless.

Why do I need xunit for debugging?

>>57143542
>Because in C
coding C is stupid full stop.

>>57143588
Very true. However despite being stupid it's still popular, and print debugging (like a whole other list of C shit) has potential to make you tear your hair out.

>>57143542
Wait, how?

>>57143542
This argument is both incorrect and could be made for many types of debugging. Neither breakpoints or single stepping would be any better than printf's for determining exactly which line resulted in some corruption due to undefined behavior--all they will do is help you figure out where the crash occurred, which absolutely is useful when trying to determine where the actual problem lies. Tools such as linters and valgrind *may* help determine the source of undefined behavior directly, but only for specific classes of problems--in all other cases using print, or some form of runtime notification, is still the only choice available.

If your argument is just that "C sucks" (i.e. >>57143588), then that's fine, but that's not what you said.

>>57143644
http://blog.regehr.org/archives/232

>>57143733
Thanks, that explains a lot.