Is it okay to leave tests in your code?

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."

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.

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

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.

::: spoiler Why? The reasoning for this varies but for example:

• in most settings, output is expected to be meaningful; for example a print statement in a C program is included in its result and expected to be parsable, even if it’s just a number like 0 (success)
• logging specific values can expose runtime data that sometimes shouldn’t be exposed, or can otherwise offer an attacker intel about the application structure
• debug statements in logging can indicate the dev has not yet learned to use a debugger, the preferred tool for that job
• logging non-descriptive or otherwise unhelpful messages can indicate the developer is aware of a bug they’re attempting to catch on prod, or maybe just has a habit of not cleaning up after themselves
• otherwise, obvious output-based testing might suggest the developer is not writing unit tests or maybe has no test harness at all, which for any larger application is a big red flag to most experienced developers

Again there’s no hard and fast rule against it, and whether it’s frowned upon depends on the context. For example, I actually expect slapdash logging in stuff like one-off scripts, app mockups, recently scaffolded projects, and so forth.

Also, not every codebase merits a full testing solution. I would consider it a form of premature optimization, which is more of a process inefficiency than a mistake but should still be avoided.

Most importantly, it’s OK to be a beginner. I wouldn’t think poorly of a developer due to a code smell like this. It’s more like an opportunity to learn, and IMO you’re ahead of the game for even thinking to ask. :::

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).

Following up after your clarification (thank you):

it is not okay to do, but the severity of how much of an issue it is depends on the context? Either that or it’s completely avoidable in the first place if I just use “automated testing” or “loggers”.

It's important here to distinguish the code you're currently working on, in your local development environment only; versus the code you commit to VCS (or otherwise record for progress / deployment / sharing with others / etc.).

In your local development environment, frequently you are making exploratory changes, and you don't yet know what exactly is the behaviour you need to implement. In this mode, it's normal to pepper the area of interest with console.log("data_record is:", data_record) calls, and other chatty diagnostic messages. They are quick and easy to write, and give immediate result for your exploratory needs.

In the code you commit (or deploy, or share, or otherwise record as "this is what I think the code should be, for now") you do not want that chatty, exploratory, effectively just noise diagnostics. Remove them as part of cleaning up the code, which you will do before leaving your workstation because you now understand what the diagnostic messages were there to tell you.

If you find that you haven't yet understood the code, can't yet clean it up, but you need to leave your workstation? Then you've made a mistake of estimation: your exploration took too long and you didn't achieve a result. Clean up anyway, leave the code in a working state, come back to it another day with a fresh mind. Your will have a better understanding because of the exploration you did anyway.

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.