No Stupid Questions (Developer Edition)

1023 readers

1 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 [email protected]

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 2 years ago

MODERATORS

LinearArray

Is it okay to leave tests in your code? (self.no_stupid_questions)

submitted 1 month ago* (last edited 1 month ago) by 3rr4tt1c to c/no_stupid_questions

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

you are viewing a single comment's thread
view the rest of the comments

[–] bignose 1 points 1 day ago* (last edited 1 day 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.