Like if I’m using print statements to test my code. Is it okay to leave stuff like that in there when “publishing” the app/program?
Edit: So I meant logging. Not “tests”. Using console.log to see if the code is flowing properly. I’ll study up on debugging. Also, based on what I managed to grasp from your very helpful comments, 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”.
Following up after your clarification (thank you):
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.