I use Unreal quite alot and while I do print stuff to the log, for rapid prototyping I print string because it saves me precious seconds. Finished products will have logging for alpha testing since there’s alot of log spam
You can’t run a debugger on a customer’s machine.
Not with that attitude!
Later on when I want to look productive I’ll delete all those printfs then pay myself on the back for committing a lot of code changes that sprint and for reducing our log storage costs by 75%
Don’t delete printf statements…wrap them in a “if (DEBUG)” function. You still reduce the log storage costs while simultaneously expanding the code base and giving yourself a way to debug the system later.
As someone who has done a lot of debugging in the past, and has also written many log analysis tools in the past, it’s not an ether/or, they complement each other.
I’ve seen a lot of times logs are dismissed in these threads recently, and while I love the debugger (I’d boast that I know very few people who can play with gdb like I can), logs are an art, and just as essential.
The beginner printf thing is an inefficient learning stage that people will get past in their early careers after learning the debugger, but then they’ll need to eventually relearn the art of proper logging too, and understand how to use both tools (logging and debugging).
There’s a stage when you love prints.
Then you discover debuggers, you realize they are much more powerful. (For those of you who haven’t used gdb enough, you can script it to iterate stl (or any other) containers, and test your fixes without writing any code yet.
And then, as your (and everyone else’s) code has been in production a while, and some random client reports a bug that just happened for a few hard to trace events, guess what?
Logs are your best friend. You use them to get the scope of the problem, and region of problem (if you have indexing tools like splunk - much easier, though grep/awk/sort/uniq also work). You also get the input parameters, output results, and often notice the root cause without needing to spin up a debugger. Saves a lot of time for everyone.
If you can’t, you replicate, often takes a bit of time, but at least your logs give you better chances at using the right parameters. Then you spin up the debugger (the heavy guns) when all else fails.
It takes more time, and you often have a lot of issues that are working at designed in production systems, and a lot of upstream/downstream issues that logs will help you with much faster.
Ahem, I’m a senior developer and I love prints. I appreciate debuggers and use them when in a constrained situation but if the source code is easily mutable (and I work primarily in an interpreted language) then I can get denser, higher quality information with
printin a format that I can more comfortably consume than a debugger (either something hard-core likegdbor some fancy IDE debugger plugin).That said, I agree about logging the shit out of everything. It’s why I’m quaking in my boots about Cisco acquiring Splunk.
Splunk is already very expensive to be honest, with their policy of charging based on indexed logs (hit by searches) as opposed to used logs, and the necessity for a lot of logs to be indexed for 'in case something breaks '. Bit of hearsay there - while I don’t work for the team that manages indexing, I have had quite a few conversations with our internal team.
I was surprised we were moving from splunk to a lesser known proprietary competitor (we tried and gave up on elasticsearch years ago). Splunk is much more powerful for power users , but the cost of the alternative was 7-10 times less, and most users didn’t unfortunately use splunk power user functionality to justify using it over the competitor.
Being a power user with lots of dashboards, my team still uses splunk for now, and I have background conversations to make sure we don’t lose it, I think Cisco would lose out if they jacked up prices, I think they’d add value to their infrastructure offerings using splunk as an additional value add perhaps?
With the acquisition my concern partially lies in cost but is more focused on quality. Cisco does big expensive stuff with big expensive certifications. I’m concerned they’ll try to enterprise and make HIPAA compliant and (add insane features here) with the result being a quickly degrading customer experience.
My company has developers a plenty - but we also have a lot of less technical people who give our platform value… splunk makes our logs accessible and usable to those people without requiring a technical liason.
I’m concerned with needing to divert developers (and like, senior ones that have a lot of trust) to find better solutions or, god forbid, try to roll our own.
I’ve spent inordinate amounts of my career going through logs from software in prod. I’m amazed anyone would dismiss their usefulness!
because, sometimes, having your program vomit all over your console is the best way to remain focused on the problem.
Similarly, every once in a while I’ll throw warning messages (which I can’t ship) to encourage me to go back and finish that TODO instead of letting it linger.
Exactly. And there’s plenty of places where setting up a live debug stream is a massive PITA, and finding the log files is only a huge PITA.
Edit: But I’ve been promised AI will do both soon, so I’ll stop stressing over it. /s
This is the reason for me. Sometimes I don’t want to step through the code and just want to scan through a giant list of output.
Sometimes, I don’t know what’s wrong, I just know that something in a specific area or small set of variables isn’t working right. It’s a lot easier to notice anomalies by looking through a giant wall of print statements than by stepping through the program. “Oh, that value is supposed to be in the range [0,1), why is it 3.6857e74?”
Because, sadly, I more often than not do NOT have access to a debugger.
Learning how to write good debugging print messages is a skill. And nicely transfers to writing good debug log messages. Which makes diagnosing user issues much easier.
You’re gonna want logging in production…
I used to work on a debugger. It was called TotalView, and it was a really stellar multiprocess, multithread debugger. You could debug programs with thousands of cores and threads. You could type real C++ code to inspect values, inject code into a running process, force the CPU to run at a given line, like a magic goto. But we had a saying “printf wins again”. Sometimes you just can’t get the debugger to tell you what you need.
Because it’s significantly slower to analyze a series of computations and their values when stepping through them
Because if you invested a lot of time on carefully choosing the places where
printfshould be to get all the info you need, you just need to unsetNDEBUGand voilà everything that you need is there again.Or, for cases where you’re doing that, use actual debug or trace logging if that is an option.
I do automatic testing, debug is a waste of time
The issue is a debugger will trigger every time. In video games at least you have code that runs as over and over again in tick. Putting debugger breakpoints in that would be useless most of the time. Print is where it’s at for ticking/timer debugging.
Many debuggers (at least in the Java world, which is what I’m working with for a living) support more advanced features like only triggering the breakpoint if a certain condition is reached or only every X hits of the breakpoint.
Also, if you try and debug using print in the main game loop, wouldn’t that write so much to console/log that it’s effectively unreadable?
So first, visual studio had that too but the integration with unreal is hit or miss. You can’t really do complex conditions.
Second, you lock it behind a conditional and it’s much easier to read. Like if you want to ensure the force curve of your jump matches what the float curve you give to the designer is set to then printing out and spot checking a few is much better than using float compares that would be broken in the same way in certain platforms where floating point data is interpreted differently. So you are the data on Windows, it’s different on Linux and this you can’t just compare it because it matches just like it would in windows.
Third, if you really want you don’t print to screen instead of log which if you give a key entry, it will just update it rather than spam your screen.
Overall even the most experienced engineers in the games industry uses printing of the values at times. Debuggers are of course still very preferred for most things.
I have to print f to show respect.
Quick printf vs. setting up conditions.
Because for all the love I have for NGRX, debugging it is kinda hard.
