No Stupid Questions (Developer Edition)

1134 readers

3 users here now

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

founded 3 years ago

MODERATORS

Vacant@programming.dev

Is it okay to leave tests in your code? (programming.dev)

submitted 1 year ago* (last edited 1 year ago) by 3rr4tt1c@programming.dev to c/no_stupid_questions@programming.dev

4 comments fedilink hide all child comments

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

top 4 comments

sorted by: hot top controversial new old

[–] heavydust@sh.itjust.works 0 points 1 year ago* (last edited 1 year ago) (1 children)

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

[–] Septimaeus@infosec.pub 0 points 1 year ago (1 children)

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.

[–] heavydust@sh.itjust.works 0 points 1 year ago

Its not a best practice IMHO. Its never OK because of the 3 alternatives that exist, and because its forbidden in some regulated jobs.

[–] bignose@programming.dev 0 points 1 year ago* (last edited 1 year ago)

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.