No Stupid Questions (Developer Edition)

It's never OK in my experience.

If its debug logs, call the logger instead of print, like Log.debug() or something. If its part of a test, it shouldn't be in the code itself. And it's not a feature either as you said. Neither logs nor test or feature: remove it.

It may also bite you in the ass one day if the output is stored or tested or filtered and someone wonders who added that unspecified stuff. We never print anything raw like that at my job, and if I saw this I would wonder who is printing random crap and I would remove that because its "useless for the application."

The question mixes up tests and logging. You are referring to logs.

Use a good logging package. It will allow you to distinguish at least (possibly with verbosity levels)

• trace
• debug
• information
• warning
• error

In production, configure the log level to be info-level or above, everything below will be hidden.

Lower levels can be useful for debugging automated tests. Possibly via a flag in production as well.

my team was driving me insane with leaving console.log("here") all over the place in every pr, so now we have a "no console.log" eslint rule in ci.

I guess my answer is it depends on your team. good logs are different, but imo if they're just debugging statements they shouldn't even make it into the repo let alone prod.

if it's just you, do whatever you want lol, performance is almost certainly not significant and most users should end up ignoring them anyway

It's my opinion that typically all published apps should employ automated testing, in the form of unit tests, integration tests, and so forth.

As far as logs and print statements go, it probably depends on the context. Like, useful feedback and debug logs are usually good. But step by step test logs not so much, especially if the end user will be inundated by them.

Are you familiar with automated testing? From the subject line I thought this was going to be about that, but the body of the post is something else.

Great question.

There’s no universal rule against it and descriptive logs and errors are considered good practice, but one-off test statements in output are a common code smell, which isn’t a proper bug but suggests there might be one elsewhere.

Edit: use spoiler for info dump

It depends.

Whats the user impact? Do they see it on regular use? Do they see it if they look for it? Is that okay? Maybe even helpful for users to debug for themselves or to report issues to you?

Will the log statements remain useful in the future? Or is it noise both in output and code that will reduce readability and maintainability by burying more relevant things.

If they remain useful but more situational and lead to noise, consider putting them behind log levels or configuration flags (even if not app or configuration but a code flag).

It depends where.

Open source project other people will use, and may need to fix? Please leave them in! I love it when I can read the debug output, find the issue, and tell the maintainer how to fix it.

School assignment or professional setting? Take it out or replace it with an official looking "logger" (which will just be printf anyways).

In general no. They aren't even ok during development. Instead you should learn to use a proper debugger. They let you break at a certain point, inspect all the variables, step through the program.