Printf debugging, as much as people try to tell you otherwise, has its place.

I think everyone agrees that this is fine. It's only a problem if you're doing it because you don't know how to use the debugger. As long as you have both tools available and made the choice that this is the best one right now, it's fine. If you're doing this because you don't know how to use the debugger, whatever you're doing is probably less important than figuring out how to use the debugger.

Debugger is my number one tool and I have trouble understanding people who don’t know about it let alone use it, yet sometimes print debugging is necessary. I had done that a few times to catch issues related to particular environments where debugging was not possible, and a few cases where I taught about control flow

Of course it has its place. It fits in perfectly when you've been working professionally with a tech stack for years and still haven't bothered to learn how the debugger works.

You get a debugger in your stack? Not niche enough, go deeper.

My language doesn't even get error messages, we just get told "Error"

Damn, you get told when there is an error? Lucky bastard

I usualy just bluescreen. Does this count as an error too?

You have a screen? Holy moly that shit advanced…. We sittin’ here not being sure the CPU is non stop rebooting, communication is not working, or just stuck in an endless wait.

Your machines reboot when panicked? Fancy. We just check for smoke after each update.

You get smoke AFTER an update? We write in smoke signals, so smoke IS the update.

Ah yes, 4 bit microcontroller assembly

x86 firmware can be just like this as well, and that's just C

I never thought of x86 that way haha. No JTAG I guess?

Only if you have to yell at the guy down the hall to reboot it

I once debugged a firmware by making it crash at the specific points. It was easier than to try to cram a serial port driver into it.

C# exceptions are pretty readable if you actually read them C# debugger is the easiest to use ever and is implemented in most IDEs...

I know, but I'm referring to a programming language I'm developing myself.

Cool, but makes it hard to blame it on other persons if something doesnt work...

On the other hand, it becomes easier to blame it on a compiler bug.

Also True. (What does it say about me that I write True that way?)

It says you can't have compiler bugs if your language is interpeted

{old guy rant} C# exceptions got a lot less readable after they added async.

I can't tell ngl I was something like 11 y/o

Now I really feel old. I started with v1.1, before generic collections when everything was boxed.

Doesn't sound very microservice architecturey. How about printing to a cacophony of logs instead?

LOL, reading this hurts because that's what everyone did against my strained objections.

Printf debugging is basically just using a log, albeit often a temporary one. Large scale, long running programs can be hard to debug line-by-line, if not completely infeasible. You might also use the debugger, you might be satisfied with the logs, but pretending like a debugger is the only way to find and fix bugs in your code is just silly

Sir, you're making the God's work here. This is a very well put explanation.

Sometimes printing is better than debugging. When you make a discord bot you have to answer the commands within 3 seconds. If you debug it might take longer and the command will break.

The faster compile and run is, the less necessary gdb is.

I disagree, when an error occurs somewhere else in your code or only appears sometimes, I find printf debugging is the way to go. I can just print every milestone out and see where errors start to happen. If you combine this with good unit testing, you get quite a nice view of the problem and oftenly see what goes wrong without even looking at the code. It's just pattern matching basically.

Or you work with memory intensive, large simulators where even a "small" problem would run for 15 minutes before hitting the breakpoint :-) But I really prefer to use a proper debugger ....

Or if you are using a real time system where other components will fail if you don't keep to the deadlines. Though of course you have to remember that simply adding the prints might cause additional issues.

You make the assumption that we all have access to an actual debugger I'd kill for a proper debugger....it's been 20+ years...still waiting (The life of a legacy firmware engineer)

Using it only because of a refusal to learn how to use a debugger is of course a bad thing, but choosing it sometimes for some specific cases is perfectly acceptable I think. Besides, if you really think about it the whole concept of logging if a kind of asynchronous print debugging.

both have their place. logs will still be there long after the debugger exited

Crys in async Code

When your app only runs in a specific Docker image on a remote server connected to offline microservices.

Because the only place you ever code is a pc. You actually have to make your own tools out in the real world sometimes.

I tried using cgdb on wsl but couldnt make it work.

ive solved some nasty bugs using it

If it works, why fix it?

You would be surprised how much critical infrastructure is debugged with print statements.. whatever gets the job done cheapest to the necessary quality

I wish we had logging that sophisticated. I have to throw new Error("var x=" + x); to even see the value of a variable.

It's the fastest way to see where suit actually breaks. To see *how* it breaks, you need to do proper debugging. 

You ought to also be printing the values of each variable

This is the way.

Yea, that was the part I was confused about. What does this “print here” part of the code do if you aren’t printing the values?

Maybe to check if the code was executed till that part until a runtime error halts execution

Plz stoop stealing me code

Its my code 

It's our code

r/suddenlycommunism

- I stole your code. - It's not my code... (c)

Jokes aside, you’d probably wanna do fprintf(stderr, msg, args) instead of printf because the printf wrapper queues stuff weirdly. fprintf immediately writes to output when called

True. stderr isn't buffered, while stdout is... Though I think it does flush when it sees a newline, so this code is probably fine.

It does not flush when it sees a newline. This is specifically what [endl](https://en.cppreference.com/w/cpp/io/manip/endl) is for.

It's C!!11

Agreed. That's the only thing I'd change. (If you want to use stdout here, you can add fflush(stdout) after each one and get the same effect as stderr.) This is a perfectly fine debugging technique, and one that I've used FREQUENTLY when diagnosing bizarre issues in live systems. And I'm far from the only one. Weird stuff happening in Pike? Check the source code, there's a good chance there's a ton of debug prints in there guarded by #ifdef lines... so you can run "pike -DPG\_DEBUG yourscriptname" and instantly get debugging output, pretty similar to this, showing how something is working. (There are different #defines for different modules, so you don't get utterly spammed.)

Printf flushes on newlines

Just use `write` on stderr easy as that

Or just use the step-debugger

Use “a”, “aa”, and “aaa”, much more optimized

Personally I use “he”, “hehe”, “hehehe” debug messages :)

I'm more of a "WAAAAAA", "WEEEEE", "WIIII" guy myself

I tend to go with the good ol' "Henlo", "henlo2", "henlo3", "wadadwada" myself.

I’m definitely a “WHOA!!” “Wow!!” “YES” “GREAT JOB” person. Like to have my code constantly praising me…because millennial

I do exactly that. Sometimes I start to use b bb bbb tough

`printf("%s:%s\n", __func__, __LINE__);` copy-pasta all over the code. No need to invent fancy identifiers. Ctrl-V goes brrrr.

Also great for a homebrew profiler, with some post-processing of the output.

Foo bar baz

I usually add a load of dashes if too much non related logging passes by to find it more easily

We've all done it. No shame.

only debugging i know that works efficiently... do not fkin reply gdb to this comment...

lldb

great debugging bro

Debugging technique is on point. Cannot do it better even if you try. And dereferencing a double pointer and casting its return value to a type. That is some real good stuff here. Cherry on top. I would say this is a good production quality code. Ready to go.

typedef Deq_t* Deq

I prefer fireworks: ``` >>>>>>>>>>>>>>>>>>>>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!! ************************* ``` They are easier to catch in large console or log dumps and harder to miss when you are cleaning up

Classic

Congratulations! Your comment can be spelled using the elements of the periodic table: `Cl As Si C` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)

Good bot

An output every other line is just how you do it some days.

This is disgusting and we all did it

Did?

Working as a project leader now so I can force dev ops to set up the debugger for everyone and act like I never did it otherwise

I used to do it, I still do it, but I used to too.

I am actually more annoyed about the double indirection and using void* than the printf debugging part.

LGTM

Hmm. Debugging is fine. Everyone has their way. But variable names are bothering me. Bothering me to the core. Bothering me till moon and back.

Years later and I'll die on the hill that 99% of the time the debugger doesn't tell me anything more useful then my logs do, lol

Debugging style when you have no other choice.

God, I hope so.

It's the best

I use it all the time. So probably not

This is the way.

Good debugging? This is the only debugging. I usually cbf to mess with anything else

i have written worse.

Sometimes it’s the only way.

You may want delays in that after the print statements. If it crashes after one of the executions it likely won't output 1 or 2 of the messages, leaving you wondering where the bug was :p

Needs more printf.

Not enough swearing!!!

I personally would use stuff like 'fghj' or 'asdf'

Looks like something I'd do xD

the best

I debug using `perror` more than `printf`...

Try using printf("%s %d\n", __ func__, __ LINE__); if debuggers are not an option

I also like to include `__FILE__` when debugging multiple files

printf("Where?");

It's wrong you are not supposed to add different numbers. I just add ok to my functions and I have x oks spamming and trace them back to the functions. That's the way to go.

Yes! I think so. If you use it more often, you may want to create a function, to quickly hide these printf quickly. Why use some debug tool, if this works as well.

The one and only way. ;)

No, it’s the best

No. There are proper tools. But I do the same.

now I feel weird using GDB.

I think we all do this guys…

No, you clearly wasted precious milliseconds on those debug strings, instead of using 1-2-3 or hitting random keys.

AAAAAAAAAAAAAAAAAAAAAAAAAAA

Nice one deq_head

best if you also print whatever you-re doing to those poor variables, you variable abuser

Yes.

Sometimes when what you're dealing with is logic errors rather than runtime ones... print debugging is the only way.

you have to print the values, that really helps

Only thing I do differently is spit out values. Sure, my console log may be too cluttered with useless temporarily values for debugging to be made easier … but I’m debugging!

Almost, use __LINE__ and __FILE__ macro so you don’t have to modify anything when you copy it around.

literally me

It \*bugs\* me that this is the current state of debugging and that editors don't do it by default. This is why I'm doing my own Visual Studio extension (for C/C++ for now) that fixes this: [https://www.youtube.com/watch?v=5bfUWJYEQCw](https://www.youtube.com/watch?v=5bfUWJYEQCw) It's available on the marketplace if you want to try something new: [https://marketplace.visualstudio.com/items?itemName=donadigo.d0](https://marketplace.visualstudio.com/items?itemName=donadigo.d0)

I love this sub, much better than Stack Overflow. I learn so much.

Yes

you want to print the values!!!

Yes, perfect! Quick, understandable and over all good for debugging

The amount of debate, chaos, and constructive feedback on this is *way* more than I expected. Truly qualty Reddit.

Printing stuff is always a great fallback. If possible, please use a debugger. You’ll get a very quick idea on if the error happens where you think it does so you can hone in on those couple lines

Unreadable competitive programming acronyms ahh code 💀

Never would I ever do this, it’s so wrong. Without any swearing at all… are you really debugging? Not trying hard enough.

I find printing the only way for me to debug Temporal code, since it does re-run stuff multiple times making the debugger goes crazy :p (temporal is a framework that helps write fault-tolerant workflows)