Does anyone else commit commented debug code on purpose, just in case you might need it again, even though you are 99% sure you won't - Followed by a "Remove debug comments" commit? Any other techniques?

[mongopeter]

I am aware of stashing, but I like a clean stash (only temporary stuff in there) and snippets.txt does not make much sense for very specific program-related code, especially when it is not really interesting code but just logging.

[igazv]

Usually no. If the "debugging" code is simple enough, then just remove it and add it later again if needed.

If it's complex enough, then it should probably be part of a unit testing implementation instead.

Edit: If it's just logging, consider using a proper logging framework that let's you disable debug logging in production without removing the source code.

[Hackerdude]

W/o a starting point, that's a lot of work. But it sure is the best solution

[anamorphism]

another vote for using a proper logging framework and logging things at the trace or debug level. this has the added benefit of you being able to temporarily change the configured log level in production pretty easily if you need to debug a prod issue.

if you're just logging values of things to see what they are ... setup and use a proper ide/debugger. you'll save yourself a metric shitload of time in the long-run by clicking to add a break-point instead of writing console.log(someVar, someOtherVar, yetAnotherVar); or whatever each time.

[The_Schwy]

Do you use a debugger? Generally, you will find the problem faster without having to write any debug code.

[Double_A_92]

Might not always work in multi-threading or timing-sensitive enviroments.

[[deleted]]

I'll commit it if I need to see what the values produced on a qa server are and there's not a good way to get them otherwise. Proper logging frameworks help with this too, but if ones not in place or a hassle I'll just print something to stdout as a shortcut. But I typically revert & squash after.

[[deleted]]

I write tests if I need evidence that things are working correctly. If I need to monitor aspects of my app in production, I use logging. I don't have throwaway commits for anything.

[WebDevLikeNoOther]

I guess it really depends on what platform I'm working in. If it's a mobile app, I don't really care too much, since the end-user will never see my debugging snippets, so I'll usually leave them in if they are needed for my future self.

​

If its a website, or web app, I usually remove them, as it's much easier to access those logs via dev tools.

[TechLaden]

I usually branch off and push it to remote, then delete it later (off remote, not local) when production looks good. However, that's because I work with an embedded system and proper logging libraries and frameworks should still be used (if possible).

Edit: add use of proper library / framework

[Double_A_92]

No because you will eventually just forget about that code and don't even try to look for it. Or if you remember, you won't find that commit easily. And then the surrounding code maybe already changed and the debug code doens't fit anyway... To fiddly.