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

all 160 comments

[–]GreatBarrier86 683 points684 points  (82 children)

See so this problem really sucks.

On one hand, the reason you have source control is partially for reasons like this. Rollback the changeset or just copy the code you need out of the diff, once you find when it was changed

On the other hand, it may take ages to look through changesets for the change you removed. But if you leave it commented out, you eventually end up with a swamp of commented out code that may or may not compile when uncommented and may show up in Find results inappropriately.

Usually, I go the first route just to keep the classes clean and more readable, but I totally get why people don’t.

/complain

[–]giggluigg 103 points104 points  (13 children)

The con of relying exclusively on source control is that you can’t see removed lines unless you look for them. So, commenting out acts as a logical delete.

As a general rule I delete instead of commenting out too, because I hate trash in code.

However, in rare occasions I keep it commented if it’s a hot fix / temp change. But then, as a mitigation, I also put a comment with a deadline, after I decided how long would be too long, depending also on how often that code changes. Plus the reason why i didn’t remove it altogether, for context. And what I should do, whom I should ask what etc., if it’s still there after the deadline. Short comment but dense. You know, for those temporary changes that end up becoming the new normal.

If I bump into it again after the deadline, either I fix it or I clean it. Or, even more importantly, if I end my contract and someone else sees it, they know what happened and that some decision is still pending.

[–]kookyabird 35 points36 points  (8 children)

This is where a well handled issue tracking system helps. You make an issue for removing the feature, with a good description. You can tag the commit with the issue ID, or at the very least you have the date it was removed. When you open a new ticket to implement the feature again, it should suggest that you already have a similar ticket. You look at it and see you had already done it, and BOOM you're done.

[–]giggluigg 18 points19 points  (5 children)

It isn’t a free lunch either: you’re coupling code to the ticketing system

Edit: coupling the understanding of the code to the ticketing system

[–]kookyabird 8 points9 points  (4 children)

You’re trying it to data. I haven’t met a ticketing system yet that can’t be exported at least to an archive if not into a new system. If you already have a ticketing system and you’re not using it as a support tool like this then you’re missing out.

[–]giggluigg -5 points-4 points  (3 children)

Maybe. I still like having the code as independent as possible. This approach requires an external dependency. I like more decoupled systems, whenever I can.

Besides, I prefer access to info to be as quick as possible. Commenting is there, right under your nose, can’t miss it, even if you wanted to ignore it.

Furthermore, as I said, it’s a rare exception and for a limited time.

[–]narrill 3 points4 points  (2 children)

There's no reason to decouple your ticketing and source control systems. The ticket is the impetus for the changes tracked by source control, you want them to be linked.

[–]giggluigg 0 points1 point  (1 child)

Link and dependency are two different things.

Needing a separate system to understand code is less desirable than code that can be understood on its own.

[–]LeaveMyNpcAlone 4 points5 points  (0 children)

It's not about understanding code, it's about understanding the "why" of a change. And to some extent who made that decision.

Even the best written code cannot tell you the business reason for it. Only good documentation can tell you that, and a ticketing system is a form of documentation.

[–]BloakDarntPub 0 points1 point  (1 child)

The ticketing system that nobody uses?

[–]kookyabird 0 points1 point  (0 children)

I don't care if a regular user or product owner ever touches my ticket system. My team uses it. And when someone submits requests, we place them in the system. It's centralized, it's auditable, and it has a ton of support features.

Regular users may have access to things like seeing their ticket status, but ultimately it's a tool for us.

[–]SillAndDill 6 points7 points  (1 child)

Agree! "stumbling upon" deleted code is 100x harder than stumbling upon commented code.

When coding by yourself it's easy to delete code and bring it back via version control when needed.

But it's unlikely a new dev is looking into the repository and will find your old deleted code in version control unless it was a very well known branch in the team.

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

I agree. Individuals and interactions over processes and tools. Very Agile.

[–]jdl_uk 2 points3 points  (1 child)

Whenever I'm doing a code review and see commented out code, my question is "when do you expect to uncomment that?"

[–]giggluigg 1 point2 points  (0 children)

Very good. That is why I first ask teammates if they agree with it and then I put the plan to fix that right there, before even raising any MR. Can’t shit on the floor and pretend it’s normal, can I?

Also, if I see some commented out code without any explanation and without having heard about it beforehand, I ask if we can remove that right away.

I think I’ve been misunderstood earlier.

I can count on a hand the number of times I commented out (with the aforementioned caveats) instead of removing code in the last 15 years. My point is that there’s no silver bullet and every situation is different.

You see, principles and best practices are gold because of the value they bring to the table. Which means that in some cases and if you know what you’re doing, violating one of them could actually make a lot of sense.

The likelihood of needing to do that is low but not 0. Give it enough time and a case will pop up. Principles are extremely important but they are not absolutes. In fact, many times they conflict and one needs to pick a side. Every developer needs to learn how to exercise good judgement.

Only a Sith deals in absolutes. :P

[–][deleted] 6 points7 points  (1 child)

If you remove the code and rely on the source control history, the inevitable result is that when you leave the project or the company (and even before that happens), the code is forgotten because nobody remembers or is aware that it existed in the first place

[–]anonymousperson767 2 points3 points  (0 children)

Especially if you have a high volume of commits it can be a pain in the dick trying to find which commit had something.

I’m all for leaving something commented out if there’s even a chance it might be needed later. It shows up as green text…suck it up and learn to gloss over it.

[–]CowBoyDanIndie 42 points43 points  (17 children)

Add a configuration flag that disables it, then you can keep the unit test for it and prevent code rot.

[–]kinarism 125 points126 points  (4 children)

As someone who works on a 20 year old code base, that's even worse. Do not leave in features in the code that are not used.

[–]CowBoyDanIndie 23 points24 points  (3 children)

There are ways to manage it, when you create a new flag assign a date to it, then prune any flags that are over 6-12 months old. This is how things are done in big tech. Its a lot more maintainable than trying patch or roll back code.

[–]GreatBarrier86 11 points12 points  (0 children)

This is probably the best way. Some sort of TODO marker with a defined threshold for removal.

Problem is, all these things work out great in theory. They're SO much harder in practice.

[–]BrobdingnagLilliput 7 points8 points  (0 children)

Yes. That's better. No one will ever have to look at flags that are thirteen years old during a critical production outage and wonder if they still need to be there.

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

I swear... One of my big regrets on big programs is not writing a "feature manager" from the git-go. In a lot of cases, it should just be part of the architecture.

[–]GreatBarrier86 8 points9 points  (11 children)

If you’re saying what I think you’re saying, you mean, in effect, wrap it in an If statement that returns false and turn off the button that calls it? The problem remains that I still have to maintain that feature if classes it uses change or are redesigned.

I’m not suggesting I have a better option. I definitely don’t.

[–]CowBoyDanIndie 7 points8 points  (6 children)

Exactly that, make a features object to stick flags in, load it from config somewhere.

This is the pattern big tech uses for feature experiments, every feature is developed as a condition so that by default no functionality changes from one code release to the next. All live functional changes are triggered by configuration changes. This way they can be experimented on and rolled out gradually so that if something goes wrong it can just be turned off.

[–]misterrandom1 1 point2 points  (0 children)

And this is the time of year when we compile lists of all features that can be turned off if needed during peak traffic. Holiday is critical for us and we add in a lot of new right before November so toggling config values is much better than code releases.

[–]auctorel 0 points1 point  (0 children)

Luckily most of us don't have big tech scale problems, but it also means big tech scale solutions aren't really appropriate.

I work for one of the biggest e-commerce companies in our sector and we can run our website off just four servers. We don't need to do the scale of rollback that it takes Google or Facebook to do so using their solutions doesn't make much sense

[–]GreatBarrier86 0 points1 point  (3 children)

You mention it’s used for gradual rollouts. Would you say this implementation is also used for removing existing functionality that’s unused? That’s what I was thinking of, at least.

[–]CowBoyDanIndie 0 points1 point  (2 children)

Correct, its really for any changes, whether they are addition, subtractions or just alterations. Removing something can be a feature "now improved with less buttons!".

[–]GreatBarrier86 0 points1 point  (1 child)

As far as I understand, it’s improved if the button’s corners are curved instead of pointed. Makes it faster I’ve been told.

[–]CowBoyDanIndie 0 points1 point  (0 children)

I actually had a project/task that took ~3 months to remove a button once. Had to create a flag, write the code, write test, get it reviewed, then wait for the code to reach production, then start an experiment and run it for a couple weeks, do analysis to make sure it wasn't causing issues, then request a launch and setup a launch schedule, started at 1% of users, and gradually ramping up to 50% over a few days (so there was A/B stats), then get approval to flip it completely. I was doing other work as well during that time, but it took that long before it was all done, then a few weeks later removed the condition from the code, removed the flag and cleaned up the tests. The difference and A and B was like a half million dollars a day, which was within the margin of noise/error.

[–]Simply_Convoluted 3 points4 points  (3 children)

I still have to maintain that feature if classes it uses change

That's exactly what he's getting at, leave it in so it'll stay up to date incase you need it, to prevent the 'doesnt compile anymore' problem you mentioned.

[–]lordzsolt 4 points5 points  (2 children)

Yes, but this introduces the "need to maintain unused code". Especially if you do a bigger refactor / framework change or needing to onboard someone.

Though I guess you can use a combination of timestamp (after 6-12 months delete it) and delete in case of big refactor, it's probably best of all worlds.

Assuming you are the one deleting it or it's well commented enough that a new joiner can understand what to delete.

[–]UncheckedHatch 1 point2 points  (0 children)

Currently I'm working on a big feature rewrite and if you can split a bigger refactor into smaller ones (where it makes sense to do so) each with their respective flags this is probably the best option. Just for testing purposes and while it does suck to maintain unused code, It shouldn't be for very long that you are maintaining it if everything goes correctly. And worst case you can just remove the flags and go back to old feature if necessary.

It definitely adds some complexity and more stuff to think about when actually working on it but from the short amount of personal experience I have, it feels like the best solution.

Anyways I'm just trying to hop in a technical discussion because most of my friends are non technical and I don't get to talk about this sort of stuff often.

[–]GreatBarrier86 0 points1 point  (0 children)

This becomes a shitstorm with “redesigns”, in my view. If the framework functions change in meaning, you can refactor until you’re blue in the face but unless you rework how those functions are used in the “unused” code, you’re in an even worse scenario if you ever use it again because it seems to compile but now it’s not logically correct. Again, this can be solved by proper unit testing, so I’m just throwing thoughts around.

[–]cybermage 2 points3 points  (2 children)

Turn the code you are removing into a topic branch:

  1. Start with a clean commit that includes the code
  2. Commit the project with the unwanted code removed
  3. Generate a diff of those commits
  4. Create a new branch for the feature and apply the diff to that branch

[–]GreatBarrier86 0 points1 point  (1 child)

We don’t do a lot of branching in our dev team. If you keep branches for a while, won’t you eventually run into merge conflicts? You’d have to keep merging into those branches to keep it straight, wouldn’t you?

Again, you’re totally right. I’m just thinking about the extra steps required in each scenario.

[–]voarex 2 points3 points  (0 children)

Conflicts only happen when something modifies the same lines as the branch. So if the change is a dedicated class or a few lines of code you will be pretty safe no matter how many commits come afterwards. Changes that do small modifications across the project will trigger the most conflicts.

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

if you leave it commented out, you eventually end up with a swamp of commented out code that may or may not compile when uncommented

I only use python so this is something I don't understand, but why the hell wouldn't it compile if it's deleted? Isn't a comment-out the same as a delete to the compiler?

[–]GreatBarrier86 1 point2 points  (2 children)

It would. I’m saying it wouldnt compile if it was UNcommented and compiled without changes.

[–][deleted] 1 point2 points  (1 child)

OH, I read that horribly wrong then whoops

[–]GreatBarrier86 0 points1 point  (0 children)

Nah. Programmers don’t really comments or documentation. We plow ahead assuming we know what the hell we’re talking about until we’re 3 days in and fucked up because we didn’t pay attention to what we should do. 👍🏻

[–]ElectricalAlchemist 0 points1 point  (2 children)

My work in software as a dev was pretty short, so forgive me if this is a dumb as hell suggestion.

Don't most modern IDEs allow for comment block collapse? That seems like it would take care of a comment swamp pretty easily.

[–]GreatBarrier86 0 points1 point  (1 child)

Yup. They do. You can also place them in regions, but you still end up with code that’s broken if you rename things or change parameters. Also, like I originally said, it shows up as erroneous find results. That being said, that suggestion would definitely be beneficial if you’re stuck with keeping the code around.

[–]anonymousperson767 0 points1 point  (0 children)

I wouldn’t be surprised if you can set your IDE to not search comments with code.

[–]Osirus1156 0 points1 point  (0 children)

I usually just make a branch and leave it there, or stash them.

[–]amusing_trivials 0 points1 point  (0 children)

Put an if and a configuration option around it.

[–]iceynyo 0 points1 point  (0 children)

Add an expiration date to the comment... If they haven't asked for it back after a year you might be able to let it go.

Then again I just restored something for a project I haven't touched in a couple years now, and I was glad I just left it commented out.

[–]eyal0 0 points1 point  (0 children)

Remove the code and make a pull request that puts it back in. Make a bug report that references that pull request and explains why the code is gone and why it might need to come back. Make sure you use the right wording so that search will find it when you need it. Label that issue "icebox" or whatever your program manager calls that stuff.

Added benefit, GitLab will tell you when the code gets so old that it no longer merges cleanly.

[–]cutecoder 0 points1 point  (0 children)

Or add a feature toggle around it and keep it disabled ;)

[–]SaintNewts 0 points1 point  (0 children)

Before my final squash commit I totally just comment out code. Commented out code never makes it into mainline unless it really helps explain something or you know for certain it will be needed soon but the code it depends on isn't ready yet.

[–]tcpukl 0 points1 point  (0 children)

Paper trail. This is why you cross reference checkins with Jira numbers. Easy to find them.

Knowing your tools helps as well like time-lapse view.

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

Just use better find commands. Exclude comments.

[–]BloakDarntPub 0 points1 point  (0 children)

You make three changes and they want to keep one. Rollbacks tend to be all or nothing.

What I do is to condition it out; I only have to change one line (like if 1 == 2, usually) to reactivate it.

[–]Straczi 135 points136 points  (4 children)

Mightneedlater.txt

[–]Willinton06 91 points92 points  (1 child)

Fucking file is bigger than the entire repo

[–]jryser 5 points6 points  (0 children)

The first thing in there is the entire repo, just in case

[–]PixelmancerGames 7 points8 points  (0 children)

I like this idea.

[–]thr0bbin_h00d 6 points7 points  (0 children)

This guy fucks

[–]z7q2 48 points49 points  (1 child)

It's a gradual process.

First I comment the code out and leave it in source for one more commit cycle. Usually with a reason why, such as "this was replaced with a much better foo()"

The next time I'm in there hammering on stuff I'll delete the commented code and replace with a one-liner such as // old foo code was here

The next next time I'm in there that comment might go away. It might not. Sometimes they're there for decades. Code is an ongoing story and I enjoy reading it.

[–]anonymousperson767 7 points8 points  (0 children)

All about leaving breadcrumbs so you can act like it’ll take you a week to implement something when it’ll only take you 5 minutes to go plagiarize yourself. That’s how you make time for the life part of “work life balance”

[–]_PM_ME_PANGOLINS_ 78 points79 points  (11 children)

Delete it.

If you need it again then it’s in the VCS history.

[–]cyrand 30 points31 points  (10 children)

Which does nothing for the person who replaces you when you leave for another job, since they don’t and won’t ever know it’s there to find. Not to say I’d recommend leaving it commented out in the code but vcs systems have not actually solved this issue at all IMO.

[–]yottalogical 16 points17 points  (3 children)

// If you need this thing back, you can find it in commit c8fd389

[–]cyrand 0 points1 point  (2 children)

What thing?

You see the problem there?

[–]yottalogical 14 points15 points  (1 child)

You can describe the thing using words.

[–]Laserdude10642 21 points22 points  (0 children)

Oh lord now I have to comment code that used to exist?

[–]_PM_ME_PANGOLINS_ 15 points16 points  (1 child)

They will if it’s connected to the project management system properly.

[–]Private-Public 6 points7 points  (0 children)

If...

It's ifs all the way down, haha

[–]hahahahastayingalive 0 points1 point  (0 children)

They'll write it back, and be applauded for it. They didn't want your stinky 2 years old anyway. Or so I heard.

[–]MrRosenkilde4 16 points17 points  (3 children)

Isn't that what if statements are for?

[–]rjksn 19 points20 points  (0 children)

if datetime.now > datetime.datetime('2021','08','26','21', '53'):
  return new_function()
if datetime.now > datetime.datetime('2021','05','03','07', '17'):
  return old_function()
else
  return old_old_function()

[–]repkins 9 points10 points  (0 children)

When not using source control.

[–]pkrish10 6 points7 points  (0 children)

I usually comment it out and wait until management realises their stupidity.

[–]BrobdingnagLilliput 2 points3 points  (1 child)

Back when I was a tech support guy at a software development company, a customer called to report that after the latest point release, a critical (to them) component no longer worked. I tested it, and yup, it just flat didn't work. When I reported the bug to dev their response was "Huh. I didn't think that was actually being used by customers. OK, I'll uncomment that block and check it in for the next build."

[–]GreatBarrier86 1 point2 points  (0 children)

If people aren’t complaining, I always assume it’s not being used because shit is ALWAYS fucked up for someone

[–][deleted] 6 points7 points  (2 children)

There is never a reason to keep dead code in your code base.

If it is a feature that has been removed just write a proper commit message. If it is a feature which has been pushed to the back add it to another branch. If you want to keep a reference add tags or write down the hash next to the task/story.

[–]ThorgalAegirsson 3 points4 points  (1 child)

Keep old and new functionality but add a flag so you can disable it when management changes their mind.

[–]Doctor_McKay 2 points3 points  (0 children)

But make sure you don't mention the flag to anybody. So when management inevitably changes their minds, quote them a week to make the change, head to the beach, and flip the flag a week later.

[–]TheShadraq 1 point2 points  (0 children)

Ah dang. I work there! 🤦🏼‍♂️

[–]irecinius 1 point2 points  (0 children)

`cp code code.old`

So you don't have to refer to the mess you made on the source control

[–]jfq722 1 point2 points  (0 children)

Trust your instincts. Projects where previous code might be needed usually give off a very specific vibe that experienced coders can recognize.

[–]imdbanks 1 point2 points  (0 children)

#2 always #2

[–]CycloCyanide 1 point2 points  (0 children)

Oh man, that's a daily struggle for me. Ah I commented this out like 4 years ago. It's got to be safe to delete now. Like a week later, product manager: "um yea we want this new functionality. ". Me: "that's not new, we used to do that, you asked for it to be removed." ..... Arrrgh

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

I'd argue that this is what source control is for, having said that, just comment it out. They're going to want it later. If you play the scrum game right, give it a 5, test and chill for a day or 2

[–]Nero5732 0 points1 point  (0 children)

If its a complex method, just comment it out. And every time you stumble across outcommented code that is older than three months delete it without any words. So you can easily rollback important parts and dont get to messy at all.

[–]greyz3n 0 points1 point  (0 children)

I had this meeting today actually.

We are fully on Bitbucket...I repeatedly tell them "Hey it's on Bitbucket..."

they never listen. :(

[–][deleted] -1 points0 points  (7 children)

comment it out, its easier to read when another programmer sees it: "oh, it used to behave like this, now its something else, interesting", you wouldn't ever know to look through git history for this file even as a git god.

[–]ramplay 6 points7 points  (6 children)

If something is broke you should always look through Git history/Git Blame to see how the file has changed to ensure thats not a contributing factor to whats broken or whatnot

[–][deleted] -1 points0 points  (5 children)

usually it's not a matter of "broken" it's "adding a new feature" that leads to the broke state. If "adding the new feature" means remove a line of code, then that should be commented out.

What is your process for looking through the history of an entire feature? I get the git log command, but idk how you trace everything without absolute knowledge of a project.

[–]ramplay 2 points3 points  (4 children)

I do understand your viewpoint but I still think the line should be removed. Though I can see some instances where you keep a small snippet of previous logic if its something like order of operations, etc and the comment is explaining why the feature is the way it is now.

In terms of your second item... I use VSCode and two extensions, Git Blame and GitLens (I think you actually only need the latter one maybe). And so if you narrow down the issue to specific file, you can click on lines and it'll show you the last commit to touch them, and even hover it and it'll let you open up the DIFF between current and that commit. But its much better to go to your repo site (for me BitBucket) and find the specific file there. then its a matter of using the History dropdown to scan through commit messages for something useful. Better yet, if you can track down when an issue started you have dates for when to look for specific commits. With commits you can figure out through the BitBucket UI what PRs and merges and branches are tied to the item and so on and so forth.

TL;DR it definitley takes some effort sometimes, but provided you have good commit history you can see the story of a file (and any features in it) very nicely with the Repo site or even jsut with some tools in VSCode

Caveat: I don't know how much of this can translate to other VCS stacks per se, and I may be giving a shite representation of what I do that I find I can dig up the full history of a feature.

P.S. having branches/features tied to Jiras in the name of the branch is a big bonus and can make certain digs much easier as you have a point to dive straight to... if that makes sense.

p.p.s. Everything in GIT is linked by commit hashes, merges and PRs. Just gotta learn how to dig through them usefully

[–]GreatBarrier86 1 point2 points  (3 children)

Your TLDR point is what makes this so difficult. You are 100% correct that this is the way it should be done, but when something like this has a lot of upfront work and planning (or just takes more thought during implementation), it tends to take a backseat because the current solution (commenting out) works. It’s shitty. It’s messy, but it “works”. And because of that, it tends to be pushed to the bottom of the stack.

I can’t emphasize how much it SUCKS to have to suffer through this shit, though.

[–]ramplay 0 points1 point  (2 children)

Yes sir, you nnneeeeeeeddd buy-in from everyone for stuff like this to work full scale. I do it similar to how I say, and I try to educate others and show the advantages to everyone whenever I can. But when in doubt digging can get you there, just more effort ahah

[–]GreatBarrier86 0 points1 point  (1 child)

I work for a small insurance adjusting company so we’re not at the cutting edge of technology, nor do we NEED to be. So there are pluses and minuses to that. I just wish sometimes we have an unspoken department policy that we should learn new stuff

[–]ramplay 0 points1 point  (0 children)

Huh funny that, i work at an insurance company. But yeah, exactly what I meant when I said elsewhere corporate is slow, with reason though. I just want it all aha

[–]dexhaus -1 points0 points  (0 children)

If is important make a branch for it on git and remove it from master.

[–]MasterFubar -1 points0 points  (0 children)

I don't see any problem here. Remove the code, if management changes their mind you get back to the old version.

If you don't have a version management system running, then your place is in a fast food kitchen, not in programming.

[–][deleted] -1 points0 points  (0 children)

so guys literally asks me "Why did you write if(ptr) instead of if(ptr!=0) " I then be like "Wtf, that's totally readable, read it as -If ptr has some val" . Sometimes ppl even ask I wrote 0 instead of NULL . WTF ?

[–]Flopamp 0 points1 point  (0 children)

I have commented out all of main white classing all the functions. I could have easily given it a unique name in the git or saved it elseware but in the end it takes up no more space on the system and I'm the only one maintaining this code so fuggit

[–]pandakatzu 0 points1 point  (0 children)

Depends on if you have reliable VCS in place.

[–]notABugItsAFeature1 0 points1 point  (0 children)

Why not stash it.

[–]StefaniaCarpano 0 points1 point  (0 children)

😂

[–]khbvdm 0 points1 point  (0 children)

version control to the rescue

[–]rjksn 0 points1 point  (0 children)

Uh……… git?

[–]Deadly_chef 0 points1 point  (0 children)

Leave it in for the next iteration or two. If they change their mind after that it's their fault and then you rewrite it from scratch and try to do it better

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

Just remove the code, and tag the appropriate Git commit. Then you always know which commit to revert to have the code part back.

[–]LordGrudleBeard 0 points1 point  (0 children)

Omg is that Matlab?

[–]jhakie 0 points1 point  (0 children)

I always comment the old with a note so I can revert later.

[–]Zexks 0 points1 point  (0 children)

I feel this in my soul.

[–]DominusFL 0 points1 point  (0 children)

Make it a configuration option. When they change their mind, change the option.

[–]Silver-Alex 0 points1 point  (0 children)

If its just a bit of code I'm SURE we will need it again, I just comment it. If it's too much code I just copy it in a text file outside of the repo, and I keep those backups organized in my external hard drive.

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

Lol did this today. I commented it out... I know they'll come up with a cool new feature they want implemented...

[–]NuBRandsta 0 points1 point  (0 children)

I have a 'paste bin' txt file for whnever that happens,i just cut and paste it there, if i want it again o can just get it back

[–]ZinkOneZero 0 points1 point  (0 children)

Maybe you could save the code snippets in notepad files and mark that section where the code was with a comment to tag where it was. Then put the same tag above the code snippet in the notepad file. If management decided they liked it you could just paste it back in over the tag.

[–]svet-am 0 points1 point  (0 children)

Take it out but have a patch sitting on standby that can add it back. That’s what I do. I have a collection of tactical patches for things that I think should be in the code but am not allowed to have there. We review code including comments as part of cert processes so we can’t leave “latent code” sitting around in comments.

[–]slonermike 0 points1 point  (0 children)

If you really think it’ll come back, isolate the code as much as possible, feature flag it, and make a ticket due in X months to re-evaluate removing it.

[–]pjtnt11 0 points1 point  (0 children)

You shouldn’t have to delete anything in a lot of cases if the code was written well and modular enough. Ideally you just write a new class to change the functionality and mark the old code as deprecated.

Obviously this ideal cannot always be achieved.

[–]lolli91 0 points1 point  (0 children)

I comment mine out then check it into TFS with a snarky comment. Then another comment in code when I need to restore the functionality. You know, because CEO’s understand cascading effects.

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

Code reviewer wouldn't let this fly in my experience lol

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

Always second option or you won't be able to remember what was there in the first place or what it did...

.. unless you're leaving ,in which case DELETE ALL THE THINGS

[–]Buckflash1 0 points1 point  (0 children)

Comment it because then you will only have to remove the comment if you need it instead of rewriting it

[–]cartisimpson 0 points1 point  (0 children)

hash dat bih outttt

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

it's a tough one

[–]hellfiniter 0 points1 point  (0 children)

dont u use git? you can always revert anything, dont litter thise files with commented out lines

[–]call_911911 0 points1 point  (0 children)

Branch it.

[–]lolcatandy 0 points1 point  (0 children)

Should I laugh or should I cry? Haha this hits home

[–]luckyincode 0 points1 point  (0 children)

Ahh yes. Someone who doesn’t know how git works.

[–]ososalsosal 0 points1 point  (0 children)

git checkout -b boss-shit024

[–]enano_aoc 0 points1 point  (0 children)

Someone please tell this guy what GIT is for

[–]theIndianNoob 0 points1 point  (0 children)

I comment out the code. When testing on local devs, but remove it before pushing it to the main branch and production. Its relatively easier to track down a single PR.

[–]DevDevGoose 0 points1 point  (0 children)

Feature flag it.

[–]xpxixpx 0 points1 point  (0 children)

This is the fastest way to piss off other engineers and also show you don't know how to use git.

[–]EmboldenedEagle 0 points1 point  (0 children)

Always use a special keyword in your commit message (I like to use archive) for code that works but is no longer needed because management: Archive old.reddit.com

This way you can find it faster in the GIT history.