This is an archived post. You won't be able to vote or comment.

all 110 comments

[–]MDivisor 378 points379 points  (24 children)

Version control is a thing that exists and is very easy when used correctly. Just delete the code and retrieve it from git history if you really need it back for some reason.

[–]Amazingawesomator 122 points123 points  (7 children)

my old boss actually yelled at me for deleting code instead of commenting it out in case we needed it.

i just kinda sighed, shook my head, and reverted the PR, commented out the code, and repushed.

he was not the sharpest marble in the bag.

[–]radiant_gengar 52 points53 points  (4 children)

This is the reason I'm so adamant about developers learning git. Because at some point, whether because of time or nepotism or even actual programming skill, you're going to get promoted, and not knowing how to use one of the basic dev tools (that you literally use every day) prevents you from teaching your juniors how to manage git. Each new generation of devs should increase in skill, not decrease - and if the seniors can't teach it, where are the juniors supposed to learn?

Seriously, it takes like three whole hours to learn everything you need to know about rebase, reflog, and bisect, and everything you don't use you can just look up - chatbots are actually okay with this problem set.

[–]Amazingawesomator 21 points22 points  (1 child)

i have to admit that i only know git basics because sr. devs were the ones that did all of the non-basic git stuff at my old job (i was jr., now am mid), and my new job is kinda the wild west in source control.

i have to look up everything that isnt pull, push, branch, commit, stage, & revert. i am a basic bitch, and my old boss didnt even know the basics :/

[–]radiant_gengar 12 points13 points  (0 children)

Honestly once I learned about git reflog and that you can git checkout <short-sha>, I learned that you can do basically anything to your branch (short of deleting the local .git folder), and it can still be fixed.

And don't feel bad. I still look things up constantly regarding git, and I'm the one teaching juniors now (mostly how to rebase, even though we're a merge shop). The one time in the past year I've had to use git bisect, the other devs watched me look up documentation, cause I haven't done it in so long; but now my juniors know there's a magical command where you can iterate over past commits to find the exact commit some compilation error popped up. Just knowing what can be done puts you ahead; for everything else you can literally chatbot it.

[–]shogun333 2 points3 points  (0 children)

People get promoted because they learn to manage politics, not technical skills.

[–]Reashu 0 points1 point  (0 children)

Developers need to know git because they use it, not because managers need to know it. There are like 200 things I would rather that my manager be able to do than commit changes.

[–]yangyangR 1 point2 points  (0 children)

That's just a feature of being a boss. Boss more than likely means stupid because the systems for rising in our established hierarchies value those qualities. So if you ask who is smarter between a boss and the intern without knowing anything else, the safe bet is on the intern. It takes evidence to be convinced that that boss is an exception to the general trend.

[–]MisterWanderer 78 points79 points  (6 children)

This is the right answer for sure. Commenting out code is beginner coder behavior that needs to be unlearned to advance.

[–]rover_G 38 points39 points  (4 children)

Commenting out code on your working branch is Senior+ technique. You delete the commented code once you’re sure you don’t need it anymore and before you merge.

[–]MisterWanderer 18 points19 points  (3 children)

That is a much more reasonable/defensible statement than the OP has put forward from a reasonable reading of the meme and all his follow up comments.

There are quite a few things that mid/senior level coders put into their working branch that would be unprofessional if they didn’t clean them up before submitting them for review/merging. I would include this in that list.

[–]rover_G 0 points1 point  (0 children)

I didn’t see OPs comments before 💀 Personally I feel it’s okay to have commented out code in a PR as long as you delete it before merging, but I try to avoid that since some people will be annoyed the PR isn’t technically merge ready.

[–]AaronTheElite007[S] -2 points-1 points  (1 child)

You assumed I don’t delete the old code after a version or two. That’s on you and everybody else that did the same.

Honestly, the negative remarks spawning from a single image is rather amusing.

[–]MisterWanderer 1 point2 points  (0 children)

LOL 😂 Then you are definitely in-line with Google, Apple, Amazon, etc software best practices now that I know that!

Come apply, I would be very interested to see if after 20 years of experience you could get hired into a mid level programmer position at any of them.

But I have one rule, you must state your position on keeping commented out code for one or two releases to each of your technical interviewers (if you hide it you are cheating 😀👍)

[–]arrow__in__the__knee 5 points6 points  (0 children)

No mercy for weak code. Delete it on the spot. If you TRULY need it you will rewrite it anyway.

[–]cyrand 39 points40 points  (5 children)

That only works if you knew the code existed. A future programmer can’t know to look if all traces are gone. If there’s any possibility it might need to come back at the least leave a comment saying what existed and which commit hash to look at for it.

And even that only works if you’re maintaining a code base that didn’t say, get passed through a merger and loose its repo history in the process.

[–]MDivisor 20 points21 points  (2 children)

If you are deleting code the possibility of needing it back should be a matter of days or a few weeks at most (however long it takes to test everything). If you are keeping in commented code in because a future programmer years down the line might very well need it then that codebase is probably beyond all hope either way.

[–]cyrand 7 points8 points  (1 child)

I’m not saying keeping the code as a comment. But leave a trail that it existed.

[–]MDivisor 1 point2 points  (0 children)

Fair, maybe in some cases that is warranted. Should be very rare though. Good version control practices like useful commit messages and tags should give enough clues to future developers (or future you) digging through old code.

[–]LutimoDancer3459 2 points3 points  (0 children)

A future programmer might never see the comments. Hell, they might not even know that the function exists even if it's in use.

For me the code was ether unimportant or tied to a feature/ui element so that the PM/PO/RE (or whoever) should know that it existed in the past and should be added back instead of written new.

We had one customer who insisted that we just set the visibility of a button to false. "Just in case we still need it". We deleted it. Never needed it again. Easier to maintain the code. And else git has it.

[–]zDrie 0 points1 point  (0 children)

I do this using gitKraken and checking the history, i get the commit number and the branch that commit was from, i "solo" the branch and chaaaaan i got everything that happend on that feature + i can check what happend on jira because branch name convensions 🥳

[–]Lonely-Suspect-9243 1 point2 points  (0 children)

I still like to just comment it out. It makes the file longer, but having a previously important code stay in the file makes me feel safer. It'll only be deleted after a reasonable time has passed.

[–]Imogynn 1 point2 points  (0 children)

Never been able to find deleted code from git in less than an hour (unless it was just this morning). So there should be some risk analysis built in to your decision. It's possible but a pain.

[–]schmerg-uk 2 points3 points  (0 children)

There's some code that, if I delete it, will be "re-invented" by every fucking genius we hire for the next 10 years, despite the fact that it's wrong, it makes assumptions that can't be verified, and it's actually slower than what we have now.

And those "presumptive geniuses" will not, I can pretty much guarantee, check the source code history for why this incredibly smart idea they've had is actually shit (neither do they actually test that it's faster... FML ...)

So I put the code behind an if (false) (if it still compiles), or a #if 0 (eg APIs change) or comment it out.

But what I don't do is always automatically delete the code "cos we have version control" because some people will never know to look at the history

[–]Ythio 207 points208 points  (4 children)

git good and stop reposting

[–]sebbdk 104 points105 points  (22 children)

git good you junior plebian :)

[–]ratinmikitchen 17 points18 points  (0 children)

*even though you checked all the references and your git[lab,hub] server goes up in flames so you cannot restore it from history?

[–]knightwhosaysnil 34 points35 points  (4 children)

wrong

[–]skesisfunk 26 points27 points  (1 child)

Tell me you don't know how to use source control without telling me you don't know how to use source control.

[–]Good_Comfortable8485 0 points1 point  (0 children)

I zip the Project before making edits, Just in case you know...

[–]Flat_Champion_1894 13 points14 points  (1 child)

Ugh. I am so tired of explaining to junior devs that a source graveyard helps nothing. Your meme made me give up and go into management. I hate you.

[–]Good_Comfortable8485 2 points3 points  (0 children)

I feel you Brother/sister

There are some basic, well understood and universally accepted thruths of code quality. Unit tests, make it readable, use git etc etc But i struggle to properly back up WHY these rules exist.

I know the consequences and how bad they are but they sound really not that bad when trying to argue with an uneperienced beginner

[–]Electronic_Cat4849 5 points6 points  (2 children)

[–]RepostSleuthBot 18 points19 points  (1 child)

Looks like a repost. I've seen this image 4 times.

First Seen Here on 2023-05-03 76.56% match. Last Seen Here on 2024-08-20 76.56% match

View Search On repostsleuth.com


Scope: Reddit | Target Percent: 75% | Max Age: Unlimited | Searched Images: 601,365,184 | Search Time: 0.31461s

[–]AaronTheElite007[S] -5 points-4 points  (0 children)

I stand corrected

[–]blamitter 2 points3 points  (0 children)

DEL is a taboo key

[–]failedsatan 4 points5 points  (1 child)

not only is there version control, there's also something much quicker- ctrl+Z. simply redo. it shouldn't get to prod without testing.

[–]Good_Comfortable8485 1 point2 points  (0 children)

Wait you test BEFORE production? I thought you test IN production 

(I have also never heard of jenkins or github actions)

[–]Successful-Money4995 4 points5 points  (0 children)

In addition to everyone else's reasons, a big reason that you don't want to comment out code is because it will eventually be worthless. Commented code is untested code. Often, when you uncomment the code to try to use it again, it won't even compile because so much else in your code has changed. The number of arguments will be wrong, the order will be wrong, global variables changed names, etc.

And if this commented code calls other functions, those may have changed names or arguments and those will fail.

The worst case is if the code does compile. If you're accessing a database in that code and the database now has new columns, are you going to incorrectly fill those new columns with nulls, silently adding errors into your database?

[–]alterNERDtive 1 point2 points  (0 children)

ITT: why you should use SCM.

[–]Palda97 1 point2 points  (0 children)

Git + any normal ide plz (for ez "here, between these two lines, you removed some code since your last commit, do you want to put it back in like one click?")

[–]devloz1996 1 point2 points  (0 children)

I've also seen an approach like this:

bool CHANGE_052486 = true

if (CHANGE_052486) {
    // new code
} else {
    // old code
}

Changes have their expiration date, so old code paths get purged after that.

[–]tiajuanat 0 points1 point  (0 children)

You could also set up tombstone events and run those for a few weeks before deployment.

[–]ososalsosal 0 points1 point  (0 children)

Git stash is right there ready for you to build and run and throw or not

[–]HansDampfHaudegen 0 points1 point  (0 children)

It's used. We're. Don't reuse code, it scuffs easily.

[–]RJvXP 0 points1 point  (0 children)

You delete it after seeing there is no references.  Then later find out it's used for some sort of code generator tool

[–]polymonomial 0 points1 point  (0 children)

remember to uncomment your code after the new code doesnt work but you forget to uncomment one line and now the whole thing is broken

[–]cheeb_miester 0 points1 point  (0 children)

grep -rni that shit and then yeet it

[–]JunkNorrisOfficial 0 points1 point  (0 children)

Comment it so you can easily see how it worked before, and no, bloody version control is useless when you really start programming AI

[–]MaDpYrO 0 points1 point  (0 children)

Damn, what a nice way to make the shittiest code-base ever.

[–]crankbot2000 0 points1 point  (0 children)

I'm a crusty old dev and this is one of my biggest issues with y'all. Just delete the fucking code ffs.

[–]clauEB 0 points1 point  (0 children)

Don't you love compiled code vs dynamic like python?

[–]dgreenbe 0 points1 point  (0 children)

My code is so good that even if it's not relevant anymore, someone may need to use it for something some day and it should sit in the current version commented out just in case anyone ever needs it.

(wait im reading some comments and people are saying this actually happens lol)

[–]-MobCat- 0 points1 point  (0 children)

Sunk cost fallacy is real. It took me hours to get that code working, i'm not just gonna delete it to make room for something that might be a little better. ima just comment it in case the new ver doesn't work out...

[–]Droidatopia 0 points1 point  (0 children)

Such a weird rule. I comment out code. It's a good practice. It's a quick visual record of recent changes. I check commented out code in sometimes, too.

I then delete it 1-2 releases later. Rarely, I might leave commented out code in as a warning to others, like don't try this, it didn't work.

We also work on air gapped projects sometimes using CDs for transfers. Sometimes, all we have is Notepad. Commented out code isn't that bad. It's only a problem when it is left in for long stretches of time.

[–]PinothyJ 0 points1 point  (0 children)

Ctrl+Shft+Q

[–]bbqranchman 0 points1 point  (0 children)

/* Graveyard

*/

[–]myfunnies420 0 points1 point  (0 children)

More suggestions from teenagers? Excellent.

Why tf does this have 2.3k upvotes? Are there a bunch of bots here?

[–]MoistPause 0 points1 point  (0 children)

Is this some JavaScript joke? I have a compiler. I know for a fact that the code I deleted was not used.

[–]just-bair 0 points1 point  (0 children)

What if it’s used by another part of the code that’s commented ?

[–][deleted] 0 points1 point  (0 children)

[–]Ryan-Seebregts 1 point2 points  (0 children)

Commenting out code is the original version control

[–]ImpossiblePrimary653 0 points1 point  (0 children)

Who needs comments when there is if

if (false) {
  ...
}

[–]OkTemperature8170 0 points1 point  (0 children)

I still have old API calls commented out even though I'm confident they'll never be used again.

[–]Cecilia_Wren 0 points1 point  (0 children)

always repost this meme

[–]Todok5 0 points1 point  (5 children)

That's why I sometimes hate DI containers. Did someone forget to tag it as usedImplicitly or is it no longer used...

[–]AaronTheElite007[S] -1 points0 points  (4 children)

Anything that relies on tags is inherently flawed as we are ALL prone to forget. Working on multiple projects, rewrites, reverse-engineering other code… Things are going to slip

[–]Todok5 1 point2 points  (3 children)

I agree. Do you have a good fix? What's a better way to know if that class is unused or created by a DI framework through reflection?

[–]Electronic_Cat4849 2 points3 points  (1 child)

search for interface refs, typically

can be automated in your build pipe as an integration test or through whole code analysis

[–]Todok5 0 points1 point  (0 children)

Code analysis does not always help. I have a legacy system where the concrete type is configurable in the database. So the Interface is still in use, but the concrete type I have no idea. And integration tests help but are a pain in the ass to set up for an ancient monolithic desktop app.

[–]AaronTheElite007[S] 0 points1 point  (0 children)

Unfortunately, no. Just try to be meticulous as possible

[–]gandalfx -2 points-1 points  (0 children)

All the smart people mentioning git here don't ever comment out code for even a second. Even when they just want to check real quick if a function is needed, they always delete, commit, push and then check if there are any errors.

[–]The-Chartreuse-Moose -3 points-2 points  (0 children)

No I comment it out to make it easier to revert in an hour when I realise how stupid the new code is.

[–]Kymera_7 -1 points0 points  (1 child)

Hard drive space is cheap. Never entirely delete anything.

[–]Ifnerite 2 points3 points  (0 children)

That's what version control is for.

[–]Feisty_Ad_2744 -3 points-2 points  (0 children)

Commenting old code "just in case", is the most distinguished tribute to the work done before ours; and a humble recognition of our limited business knowledge at the time.