This is a place where you can ask any programming / topic related to the instance questions you want!
For a more general version of this concept check out !nostupidquestions@lemmy.world
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
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)
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.
I honestly never realised the terminology was that important (so I never put much effort into remembering any of it). Yes I meant logging. I'm having trouble understanding the rest of what you mean though.
Apologies for being too cryptic/jargon. Pro tip: a real-life mentor can adapt to your level on-the-fly, if available.
Maybe this introduction helps a bit to get an overview - from the context I expect you are on JavaScript or related.
It's often hard to grasp why packages or techniques exist unless you ran into the problems that motivated the solution yourself.
In this case, it's all about filtering by the severity of log messages (debug level). If the level is high, your app will show tiny bits of information. These do not need to show for every user, except if they want to enable it (via techniques like a switch/flag, environment variable or a config file).
Config files or profiles are often used to enable/disable code parts in production or to configure how often scheduled jobs should be triggered and so on.
Depending on your level of expertise logging stuff via the console may be just fine for the moment. In particular if you are the sole developer. Once you're annoyed by your own logs, incrementally replace the 'prints' with a library that feels comfortable or well-documented.
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.
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).
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.
They're totally ok. Sometimes printf debugging is the best option. (I agree it's not an excuse to not use a real debugger though.)
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."
I think “never OK” is overly proscriptive — we use the term best practice because there are less preferable solutions that are nonetheless viable — but your advice to use a proper logger is sound. Many developers don’t think to use them and they offer many benefits in terms of maintainability.
Its not a best practice IMHO. Its never OK because of the 3 alternatives that exist, and because its forbidden in some regulated jobs.
Certainly not best practice. The reason I referred to the term is that “best” implies a spectrum of acceptability, where the “never OK” end of the spectrum includes stuff like storing user credentials in plaintext.
But also, if anything but best practice was truly never OK, there are many smaller programs that wouldn’t see the light of day, and there definitely wouldn’t be any junior developers.
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.
This is pretty good ^
The idea that println has a a good way to test a s incorrect. It requires a testing interaction which should be avoided. Test behaviour at the exposed interface primarily, use logging/telemetry to discover dynamics.
The exceptions are reserved for scripty things (bash has poor logging,) ones offs (1x migration) or personal tooling.
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
(Guessing JS / TS) I look after a moderately sized app, and still find console.log() useful sometimes. They are all protected by a Boolean, so we have authLog && console.log('something about auth') and the bools are all set in one global file. So turning debug logging on and off is very simple.
The best thing is that when it's off, the bundler strips all the console log lines from the source, so they're not even there-but-inactive in production.
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.
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 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).