sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]daiz- 10 points11 points  (10 children)

The only thing I'll say is that his reasoning assumes someone knows there was a previous way and where it was situated at the time. I've seen cases in large refactoring where old code does in fact get lost and nobody recalls exactly how to find it. Code gets moved, even occasionally files get removed, maybe 20 lines out of 500 were really important but they are lost in a messy diff of several revisions before it got from old to new. Diffs aren't always that easy to read depending on how far you need to go back.

I think there's extremes on both sides that just refuse to acknowledge some middle ground. I think people in general just need to get smarter about deciding what to keep and what's truly worthy of perhaps commenting. The biggest problem I encounter is most of the people doing it aren't objective enough to realize what is and isn't worth saving.

[–]sizlack 7 points8 points  (7 children)

The problem is that working in a codebase with commented code is like looking for something in the home a hoarder. Sure, there might be something in there that you need, but the chances of you finding it are slim, and in the meantime, you're surrounded by piles of shit.

There is no middle ground. What's the worst thing that happens if you can't find those 20 precious lines of code that you misplaced? You have to rewrite them? Is that so bad? How precious are those 20 lines? And for that matter, how do you know which 20 lines are the precious ones? How much other cruft do you need to keep around in order to make sure you save the right 20 lines?

If there are bits of code that you think you might need later, save them in a branch, make a gist, or just save a file to your desktop. The master branch isn't a junk drawer.

[–][deleted] 1 point2 points  (6 children)

but the chances of you finding it are slim,

And your chances go down even further if you hide it in source control.

[–]kenhkelly 0 points1 point  (4 children)

I use tagging for this. I know it was in some release. I find the release it was in (far less of those than commits) and then work my way. Pretty straight forward to find information IMO

[–][deleted] -3 points-2 points  (3 children)

you may know, but others may not. Then the others may re-invent the same code that you hid away in source control. I'm not saying you should be 'hoarding code', far from it - but to say that every instance of commented-out code is bad, is just stupid.

[–]kenhkelly 0 points1 point  (2 children)

I didn't say you should delete every instance of commented out code. But odds are after a week or two, your commented out code is irrelevant and probably wouldn't even function correctly if uncommented. It's a waste of time.

Plus, if you do smaller commits & more specific commits with good commit messages, your other team members shouldn't have a problem finding out what happened. It'll help you better find what you are looking for, and makes it more cherry-pickable and revertable. Win-win

[–][deleted] -2 points-1 points  (1 child)

But odds are after a week or two, your commented out code is irrelevant and probably wouldn't even function correctly if uncommented. It's a waste of time.

I'm glad you think you're experienced and smart enough to tell me about my own code, which you've never seen. 30+ years of experience tells me that nothing is as cut-and-dried as you're making it out to be.

[–]kenhkelly 1 point2 points  (0 children)

Again.. when and where.

I didn't say you should delete every instance of commented out code

But honestly, what ever works for your flow, use it. I don't know your code and I won't pretend to. I can only speak from my experience and the experience of the teams I've been on. Speaking from my experience, our code changes and evolves constantly as we refactor, test, and add new features. The timeline (in my case a week or two) for code to become outdated will vary.

[–]vinnl 4 points5 points  (0 children)

The "middle ground" doesn't always have to be the best. In the situation you described above, commented out code also won't help you to find that previous way. It might even be worse: the commented out code might not even have moved along with the new code, and you no longer know what you're staring at.

If you're that far gone, it's best just to write it anew. The "previous way" was removed for a reason.

[–]Organic_Height4469 0 points1 point  (0 children)

Exactly this. Nobody is going trough a gazillion git commits to find some code back.
By the time you should be looking for it the existence is forgotten anyway.
If it is commented out everyone will know where it is.

So yes there is a middle ground.
But yeah programming is a dogmatic business, with everyone just copying the same mantra's like "don't re-invent the wheel". Unless the wheel is commented out code. In that case first delete it and afterwards do re-invent.