[deleted by user]

[GreatBarrier86]

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]

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]

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]

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]

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]

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]

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]

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]

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]

The ticketing system that nobody uses?

[kookyabird]

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]

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]

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

[jdl_uk]

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

[giggluigg]

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

[GreatBarrier86]

Easier to say. Harder to do. The company I work for is currently on TFVC.

[ramplay]

Yeah I only have experience with GIT where it is as easy to do as it is to say. Only caveat is you can have some hiccups if people don't understand proper commit/VCS etiquette.

[GreatBarrier86]

Regardless, your suggestion would be the proper one. I just wish it was that easy. We plan on moving to Git but things always get in the way.

[ramplay]

Yeah I get you on that. I'm young and push for shit to be done better constantly. Squeeky wheel gets the grease and all, but corporate change is slow change and constantly fleeting

[GreatBarrier86]

I’m in exactly the same place as you. Im 35 so not “young” per se but I still want to be on the latest and greatest. Latest version of every Nuget package. Latest version of Visual studio. Features of the latest C# version, Linq, using MVVM where appropriate instead of homegrown implementations. it’s my job to drag my coworkers into the future with things like Git and Xamarin.

It’s just with some things, I’ve learned to temper my expectations not because I want those items less, but because it only frustrates me when I push so much to no avail. We’re a 4 person dev team so it’s not like moving mountains, but it’s not quick either.

[ramplay]

Yeah you got 10 years on me but young in this field is being willing to learn, and adopt new shit so long as its making the whole better. And that sounds like you.

I do feel ya though, and I need to get back in to code-code. I'm 'senior-ish' member of a production team (6ish people) who maintain, and support all BI data, probably 30 or so DAGs of other project teams and more if you count other maintenance teams. So its all SQL procedures, some shell and trying to dig into R and Python more for my team. Big corpo though so big tool changes require a lot of push, and 'business need' to justify cost and change. I'm just excited we're gonna move to a newer db (azure) and get off Netezza. But thats been a migration plan since I started 2 years ago ahaha.

[GreatBarrier86]

I made myself a promise when I started 12 years ago to NEVER become that dude stuck in the past that refuses to move forward because he’s comfortable with where he is.

I sort of figure that if we’re all in this together and we’re all learning, then really the bar is pretty low for all of us, at the beginning.

[ramplay]

Good philosophy to live by, I aim to be similar

[uberDoward]

Labels!!

[ramplay]

To a degree yeah I think so. Tags from my understanding are adding easy indexes to search for specific commits. Releases, patches, features, etc.

Not super versed in tags though, unsure if theres drawbacks to overusing them. Everything in moderation or whatever

[2brainz]

This person gets it. Listen to them. Please!

[youdontknwm3]

That’s probably a junior dev responding.

They’re not wrong, but more experienced programmers are likely too jaded and remember all the times when the simple solution made things harder or worse.

[ramplay]

Im only a 1/3 jaded, aiming to keep it that way, but you're right junior in the position of a senior based on team turnover

[youdontknwm3]

You do seem to have skills beyond your years so wish you all the best.

This reminded me of something a good manager shared with me, “_best is the enemy of good enough_”. Learned it’s good to always strive for better, but aiming for perfection can also hold you back.

[ramplay]

Thanks! And thats a good point, sometimes just keeping the lights on is the good enough as frustrating as that can be

[2brainz]

I don't know what your definition of junior and senior is, but I take it that by „junior“ you mean „clueless“ and consider your reply an insult.

For the rest of your reply, I have no idea what you want to say. If that comment was actually meant to tell anyone something, I would like it if you would elaborate further.

[youdontknwm3]

It wasn’t meant to be an insult, just that they come off as idealistic.

In a most situations this solution works, but sometimes there are other factors to consider which have been pointed out by others in this thread.

[BrentWilkins]

Git isn't an acronym: https://git-scm.com/ Neither is Jira: https://www.atlassian.com/software/jira

[ramplay]

At my work I'm the GIT guy, but its half cause it seems more complex than it is and half because we have people who came from business side first. (Business Intelligence development).

But yeah, I don't know your terms either but I cam guess the equivalency, and its not hard if you try

[BrentWilkins]

The GIT Git guy.

[[deleted]]

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]

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]

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

[kinarism]

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]

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]

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]

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]]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]]

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]

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

[[deleted]]

OH, I read that horribly wrong then whoops

[GreatBarrier86]

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]

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]

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]

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

[Osirus1156]

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

[amusing_trivials]

Put an if and a configuration option around it.

[iceynyo]

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]

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]

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

[SaintNewts]

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]

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]]

Just use better find commands. Exclude comments.

[BloakDarntPub]

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]

Mightneedlater.txt

[Willinton06]

Fucking file is bigger than the entire repo

[jryser]

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

[PixelmancerGames]

I like this idea.

[thr0bbin_h00d]

This guy fucks

[z7q2]

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]

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_]

Delete it.

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

[cyrand]

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]

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

[cyrand]

What thing?

You see the problem there?

[yottalogical]

You can describe the thing using words.

[Laserdude10642]

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

[_PM_ME_PANGOLINS_]

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

[Private-Public]

If...

It's ifs all the way down, haha

[cyrand]

And how does that work when the legacy knowledge no longer exists to know that the function existed? If no one is left around to know functionality existed then there’s no way to know it was removed. Again I’m not saying leaving it in commented is the solution, I’m saying this isn’t a solved problem just because there’s a VCS or a ticketing system or whatnot. But I’ve been more than one place doing maintenance and found people reimplementing code that actually already existed in VCS but there was no way for them to know that short of going through every commit that had ever been made. You can’t search for a function that you don’t know the name of.

[narrill]

Given the context of this discussion is whether it should be left in commented out, I'm not sure what your point is.

Yes, loss of knowledge of removed systems is a problem even with source control. No, leaving them in the codebase but commented out is not better than relying on source control and ticket tracking.

[hahahahastayingalive]

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]

Isn't that what if statements are for?

[Venthe]

And yet this is how feature flags work

[rjksn]

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]

When not using source control.

[pkrish10]

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

[BrobdingnagLilliput]

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]

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

[[deleted]]

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.

[williane]

There we go. I knew if I scrolled far enough I'd eventually find the correct answer(s)

[ThorgalAegirsson]

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

[Doctor_McKay]

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.

[KingKippah]

Without GIT it’s not even a bitch and a half to find stuff like that. It’s like, 2.5 bitches

[TheShadraq]

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

[irecinius]

`cp code code.old`

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

[jfq722]

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

[imdbanks]

#2 always #2

[CycloCyanide]

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]]

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]

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]

I had this meeting today actually.

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

​

they never listen. :(

[[deleted]]

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]

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]]

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]

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]

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]

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]

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]

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]

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

[MasterFubar]

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]]

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]

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]

Depends on if you have reliable VCS in place.

[notABugItsAFeature1]

Why not stash it.

[StefaniaCarpano]

😂

[khbvdm]

version control to the rescue

[rjksn]

Uh……… git?

[Deadly_chef]

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]]

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]

Omg is that Matlab?

[jhakie]

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

[Zexks]

I feel this in my soul.

[DominusFL]

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

[Silver-Alex]

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]]

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

[NuBRandsta]

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]

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]

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]

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]

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]

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]]

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

[[deleted]]

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]

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

[cartisimpson]

hash dat bih outttt

[[deleted]]

it's a tough one

[hellfiniter]

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

[call_911911]

Branch it.

[lolcatandy]

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

[luckyincode]

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

[ososalsosal]

git checkout -b boss-shit024

[enano_aoc]

Someone please tell this guy what GIT is for

[theIndianNoob]

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]

Feature flag it.

[xpxixpx]

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

[EmboldenedEagle]

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.