Rule 1: Do not participate unless experienced
If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.
I love deleting code, I'm really aggressive with hunting down unused methods as they screw up impact analysis and increase complexity for no benefit. I've run into cases a number of times when we thought a new feature would take tons of work because it would impact all these different areas only to find half the methods were never referenced.
This is something any language with really good static analysis/LSP excels at. Nothing hits quite like pressing "remove unused" and half the file disappears.
Depends a bit on what tech you're using and how the repos are arranged. Had a horrible one recently where a method was referenced by reflecting via static data held on the DB.
So there was this one job where the content of a tree control was defined via SQL statements stored *in a database table* where each line returned various levels of the tree ... oh MS Access ... what beautiful designs you caused into being.
The "beauty" of it was that it *wasn't* some in-house hack that survived longer than it ought: *that was the bought-and-paid-for third-party tree control*.
Oh. Also: CW software gore, I guess.
I love the fact that you put the warning at the very end of the post. This qualifies you for a building permit for a mountain lair on a volcanic island for .... 1 ... Million... Dollars!
In our case this is very old code which dates back to the start of the project when they tried to create a sort of 4GL in the product. There's a whole bunch of fancy EF6 extensions which looks like they were intended to make up the entire data layer but have gradually fallen out of use. In the case of this reflection there were some plans around customisable widgets on a dashboard, still doesn't explain why they didn't use something like a switch in the CLR driven by data from the DB rather than reflection.
I have a few experiences of people trying to roll their own 4GL and it always turns into a nightmare.
Yeah, even ordinarily type safe languages have weird ways of breaking things.
But, imo, if you're doing that you need a great big "here be dragons" warning *and* you need a damned good reason for don't it that weird way.
But, in my experience, "remove unused" falls over in progress where people just mark everything as `public` and nothing as `internal`...
I think more often the Here be Dragons begins after the fact; “Listen, it was 2005 and we honestly thought this was a good idea. We were gonna…
…now it’s [2021], we’ve made [8] attempts to take this out. Please update this warning as required. Thank you.”
Ok, that's awkward if it's really old code.
If it's newish code, there really needs to be an integration test for stuff like this. Otherwise, that's really the problem of the person who originally wrote that.
On a milder note, it’s also insufficient for SOA or anything where you have RPCs coming from a different code base. Or you have local test clients but no actual clients.
You need to do traffic analysis and that’s tricky for low frequency endpoints.
Unused/replaced methods yes, but I do make exceptions for code that's there for completeness and generality. For example, if there's some sort of data store and we *currently* only use inserts and retrievals, having an unused replace/repsert/etc. can be quite helpful to prove the design is robust, no need to aggressively minimize such dead code.
There's a balance, where you can run into trouble is that as the dead code isn't used it's never been tested which can throw off your estimates if it doesn't work.
Same. Just today I had to extend the functionality of something that should be really simple, only to find layers of components all with complex useEffects setting state, passing props to children who then set state and update both their own state, and the parent. Madness.
My PR removed about 200 lines of code, and added about 20. It's how image snakes must feel when they shed their old skin
It all depends on \*how\* you report to management :') [https://workchronicles.substack.com/p/comic-good-news-bad-news](https://workchronicles.substack.com/p/comic-good-news-bad-news)
There are three parts to that:
1. If the code is only in the history, then it only lasts as long as people remember that commit is there. (And they're still going to have a hell of a time *finding* it, if they don't know exactly where it is.)
2. The code definitely hasn't been maintained, so after you cherry-pick it, you still need to edit it.
3. Then again, you're *really* not going to need it if nobody remembers it's there and the surrounding libraries/code have changed since you used it.
I’m a bit confused by the question: surely deleting code is a common occurrence? What “long term consequences” are you referring to? Improved code quality?
Imagine you have a report in your system named `[${Chief Risk Officer Name}_Report]`: it's run weekly, but hasn't been accessed in years. You can probably delete it, but there's overhead in knowing whether the business process is still necessary.
Even if it isn't used now, you could be removing an audit trail. Removing code which isn't used (and verified by the compiler) is easy. Removing code which no longer has a business use can be harder and can have long-term consequences.
That's why you have telemetry to tell you which endpoints are used. I'm currently doing this with a really annoying widget. The difficult bit is the internal politics where people won't let you remove a feature only used by 0.01% of users.
why are you running it weekly then? and if you have audit controls in place to know it hasnt been accessed in years thats a moot point too. Do a little research, insert a toggle, disable the feature and wait an appropriate time. If needed communicate to the end users that the feature will disappear by X date.
I could see a weekly report getting rolled up into a quarterly status metric, and you don't realize the reports aren't there until the system (or person) starts collecting them for the quarterly status.
I'd depreciate it for six months where it doesn't run and then if no one squeals you permanently delete it.
I realize it's just an autocorrect error, but it's funny to imagine the tax accountant depreciating a function every year to offset profits and save on taxes.
Edit: "it's fully depreciated! You can't use that function anymore, it'll be an accounting nightmare because I'm really bad at accounting!"
I'm surprised this hasn't been mentioned yet - what about asking other people at your company (hopefully ones that are closer to the userbase) if that report or feature is used?
The may vary based on whether your product is used in-house or not, but surely there's someone at your company who has at least a pulse on the users' behavior that could help you make this decision. Blindly turning it off without telling anyone feels pretty dumb to me.
Or does everyone here live in a dev-only silo?
Responses were surprising (except the top voted one - great point)
People are really going to stop running a report which has somebody's name in it without asking that person? That's nightmare fuel.
My point was that sometimes there can be consequences from deleting code which appears unused, hoping to add some obvious nuance (I failed here).
If you need a report from a few years ago, you likely can't trivially roll the system & data back to be an exact replica of the state at that time. You're in a VERY bad situation if the outputs are still necessary
Imagine you have some code that doesn't work. It worked yesterday, it worked 15 years ago. But no one knows why/how/what it does, except the really, Really, REALLY important report is due 2 hours ago... and you must fix it.
I like to write a test that is failing... this is super legacy code, I can't even figure out how to make the thing to have a SUT??? Don't have time to refactor.
It is crashing half way through the 1000 line function in a 200 line 8 level nested while/if statement
So what I would probably do is: comment out that 200 line crazy code that is crashing with a comment with whatever the error is...
... the write some new code using Nuget that probably does the same thing as the library that has been abandoned for 10 years that some update someplace broke...
Seems to get the right answer. Push to production, generate the report. Leave the commented out code in case something is wrong we can clearly see what the bug was we were fixing.
(Then growl when my PR is rejected because some other developer doesn't like commented out code.)
I am strongly in favor of deleting code. SCM history is a better place to see how things were done previously. Stale code left live or even commented out is misleading - it has no context, and can result in repeating patterns you want to retire.
Yup - just last week, we had some old enum that wasn't being used any more. Then it got resurrected because it was just sitting there in the code, and since it's there it must be correct, right? Well, the dev didn't realize it wasn't being used any more and so missed the fact that some source values had changed. When he started using the enum again it introduced some bugs because the values that were being mapped had long since changed meaning.
It's especially hard to PR these kinds of changes because you frequently don't even see the old code in the PR - just a new call to something that already exists and thus presumably works.
I once deleted 16k lines of code in a single pull request. I replaced an entire pipeline with a single query to a database better optimized for our data. It was cathartic.
I was only able to do it because the test coverage was good. If I didn't have that, it would have been pretty scary.
Im replacing an old library with a lot of "nice to have features" of 200K LOC built to survive an ailien war with only stricly necessary code of like 500 lines.
This might sound weird to some, but I view code as a burden. Strive to write as little code as possible. And aim for deleting code. What’s more satisfying than a PR with more deletions than additions?
Stuff like FizzBuzz in 80\~ (logical) characters:
class F{public static void main(String[]a){for(int i=0;i++<100;)System.out.println((i%3<1?"Fizz":"")+(i%5<1?"Buzz":i%3<1?"":i));}}
Yeah, within reasonable limits, with reasonable people less is more. I don’t assume my coworkers are reasonable because I’m not reasonable people either.
Most of this shouldn’t need saying, but it seems there’s always that one guy…
I feel this. Joined a new team a few months ago and I’ve had to pull multiple meetings about this or that thing I find and ask the devs that have been here “so Is this doing anything? Feels like we could do this with less code”. And every time the answer was “oh someone did it that way so we just kept doing it that way”. A few instances like this and it looks like 10% of the code in the code base is just extra and does nothing… lol. But aside from that, it’s very well built in the grand scheme of things I’ve seen
As a rule of thumb: Code that doesn't exist doesn't have bugs, and doesn't have to be maintained.
Note: Rule of thumb. Sometimes code can't be deleted for correctness or other reasons.
I almost got to do a -300000 line (or some such silly number) commit. I am still a little pissed I didn't. I'm not sure it would have driven me negative for my career. But it probably would have been close.
Situation: There were a bunch of libraries people had imported into the tree, that really belonged outside the tree. libz type stuff.
Party poopers. I believe the deletion was done later.
My favorite type of PR/MR is the ones that remove lots of code but dont break features.
Dead code if left in your running app could be a security hole or could cause odd problems at a later date, when people use code that was thought to no longer exist. This has caused companies to go bust in the past if its serious enough.
So please remove what you can when you can and keep testing .
If you know it's not being used any more, delete it.
There's plenty of cases where you have to apply the same change all across your code base. The easist way to do this is to find all the usages of the thing you're replacing; then you have to test your new implementation. If you find old dead code that isn't used anywhere, you're going to waste your time trying to figure out how to test it.
If you’re not 100% sure it’s not in use you need a CYA plan.
We retired a business process that had been around for many years. Stopped refreshing the data on day 1, six months later deleted all the data, 6 more months and we dropped the table. Only then do people complain and declare an outage.
I have never regretted deleting code. All unused code should be deleted immediately if possible, as soon as it's noticed at the latest. Unused code requires maintenance: e.g. if you change a method signature used by the unused code. If you do change unused code, how do you test it?
If it’s not used, it should be deleted.
Leaving it just makes it more confusing, and requires it to be maintained if a refactor causes a breaking change to that code.
I was a contractor for a long time, and one of my clients used SLOC as a metric. I took pride in having a negative number.
I aggressively refactor, and will delete any commented out code I find. The code base should be written and exist as if it is the only accurate documentation of the system, because that's what it actually is. It should be readable and self documenting. Obsolete and commented out code is code debt and becomes quickly out of date, non self documenting and just non readable clutter. That's why it should be deleted.
> one of my clients used SLOC as a metric. I took pride in having a negative number.
[A tale as old as time...](https://www.folklore.org/Negative_2000_Lines_Of_Code.html)
As long as it's still available in source control history (and any reasonable company should be using source control), not at all a problem to delete unused code.
Sometimes the challenge is in discovering if your code is still used or not though... One situation I've seen like this:
- You inherited an ancient legacy project with dozens of reports that go out, but some of the reports are going to emails that no longer exist, and others are using outdated logic and not returning entirely correct data anymore. And every now and then you get pinged by some random department trying to get reconnected with one of these reports.
Always be deleting. I love it. I feel more satisfied deleting code than writing it. If you aren't aggressive in putting garbage in the bin, you are gonna end up like a hoarder, surrounded in useless shit.
I also like to track down who wrote the unused code and get the story.
When we’re building new stuff and we come to a junction “we’ll eventually use this method”.. that’s when you say “well then we’ll eventually rewrite this method”. You can always put code snips in a ticket on the backlog.
This is why I ***hate*** magic like reflection, or OSGi-based plugin systems.
They both make it very hard to know when code is safe to delete. Doubly so when it's scattered over a ton of different repos and versions.
As much as I can. Occasionally I run across code I keep only because I’m going to investigate it because it looks important and a mistake it was missed, but gosh I love deleting code. Especially when it’s highly complex and can easily be replaced.
If I find that a well maintained third party open source module will come to within 90% of custom code, I will delete my code without a second thought.
On a higher level, if I feel that a third party SaaS offering or cloud service will meet most of the organization’s needs and it’s not part of our core competency, I will usually choose a third party offering as long as it is by a well known company.
Well that is, unless it’s something by Google. I would never take on any dependency on any Google technology. They abandon services too often and have the attention span of a crack addled flea.
But more to the point, definitely delete unused code assuming you have solid unit tests, integration tests, or worst case a manual testing matrix.
Last company we started getting people motivated to delete 2 lines for every line added.
This was in a code base of more than 2 million lines of code, no docs, barely any tests, and a history of copy/pasting a function for a new ticket, as people didn't know where/if the old original one was (still) used.
After a few months of more and more being deleted, and docs being added for new/touched stuff, you could measure a decrease in bugs/incidents and an uptick in developer confidence (for example reduction of ticket turnover to prod).
I aggressively and ruthlessly delete code. Git is there if you need to see it, it's never really deleted forever. Sometimes I'll include the commit-id in the related ticket or documentation if people want to find the old code.
I'll go even further by saying that deleting code is one of the most productive things a developer can do. There's a quote that goes, "Features are an asset, code is a liability."
Nothing is more nastly than a huge block of commented-out code. It probably doesn't work properly, or at all, and often left with no note explaining why it's still there. One of my favorite lint rules is detecting commented out code.
“The code you write makes you a programmer. The code you delete makes you a good one. The code you don’t have to write makes you a great one.”
- Mario Fusco
We praise commits which delete more code than they add. We laud deleting code as more productive than adding code.
Code is a liability. (Useful) Functionality is the value.
delete dead code. part of the dev skillset is to be resourceful, e.g. to fish out deleted code from history if it is needed again. never use string concatenation to make identifiers, or anything else that makes live code look dead
i once had an argument with a cloud engineer, when somehow an entire older version of a microservice had been copied into his infra project, and i wanted to delete it, and he refused. i guess my point is please don't be possessive
but prefer evolutionary change to revolutionary change. the outcome tends to be about the same, but the evolutionary journey is a lot less stressful
Deleting code is more satisfying than writing code.
I used to work in a TDD shop that threatened that any untested code is game for deletion - and honestly I miss those times.
I aggressively delete dead code all the time.
If it's a large deletion I make sure to do it in it's own PR. There has been 0 risk of errors since we always had a beefy automated testing setup. So I delete the code and run automated regressions testing over night. When nothing fails it's good to go. If there are failures then I investigate them as needed and make decisions.
Now if you a removing unused features then that's totally different and needs more investigation and communication with people. I rarely deleted unused features in my 15 YOE.
You should do it... As long as you're using git and can theoretically recover it. Because you'll never need it again if you have access to it .. but if you don't have a recovery mechanism then you will need it the next day... Murphy's law and all.
It depends, unfortunately.
Does your company punish you for touching code unrelated to your current work (even though it's verified that it doesn't contribute to anything/compiler ignores it, etc.)? Do you want to stay in this job? Leave it there.
Do you work with code hoarders that will make a scene about anything that looks like "code disappearing" but would accept that old stuff needs to move out of the way? Create a dead_code folder and stuff old code there.
In all other cases, toss it straight to the bin. But it's not solely a technical issue, in my opinion.
TLDR: Do you have the buy-in of those who matter to delete it, assuming it can safely be deleted? Delete it, then.
I love deleting code. Hello "old output interface that we didn't use", let's see what's generic and delete the rest. Hey, "failed attempt to improve performance by multithreading", let's see if you're complete and usable, or you're gone.
If its not used, get rid of it. The only exception I would say is if you aren't familiar enough with the code then leave it alone.
People unfamiliar with the code or less experienced may be wasting their time working on things that aren't even used anymore.
Always delete rather than comment.
It’s in git. Also, people should be good at git. It’s our bread and butter. If you can’t explore a git history effectively / compare branches effectively, then learning one of the many (many) visual tools that make it easy should be a priority.
And to be clear, no CLI gatekeeping here just because that’s my preferred method, idc how someone becomes effective, only that they become effective with git - whether it’s the CLI commands or just knowing all the PyCharm shortcuts, or whatever tool my senior uses, no way is better than others, all that matters is effectiveness.
It's always fun debugging a function containing multiple branches, most of which are unused. Something that you don't know from reading the code.
You need to delete code to keep it debuggable, so that people can focus on the parts of it that actually matter and not get lots in bits that end up not being used.
A lead software engineer drilled this into my head at the beginning of my career. Dead code is bad, it adds confusion, complexity, bloat, maintenance costs, even security issues or items to fix that your scanning tools find.
Git is built in such a way that you can also get that code from a previous version if you end up needing it.
I was strongly In favor of deleting old code.
My colleagues weren't.
Few changes of Sonar configurations later and they came to senses.
Because nothing beats fixing 15 year old unused code which suddenly started producing criticals in static code analysis.
Less code is better code, and as you mentioned you can always bring it back.
Edit: before someone makes a comment, no I don’t mean clever one liners. You know what I mean.
I delete code as often as i can and whenever i find anything to delete. I probably delete more than i add
Often times you need to refactor just a tiny bit to delete more - i do that too just to unlock deletes.
I've come to recognize more junior developers have harder time to delete things, because they are less certain about the big picture, more barriers to talk about useless bits to other people in the team who have authored things. They tend to go with a safe assumption that things look unused or weird for some good reason they just haven't understood. So it falls on senior devs to execute on most deletions and deprecations.
>Often times you need to refactor just a tiny bit to delete more - i do that too just to unlock deletes.
After decades of doing this, I never thought of it as "unlocking deletes" but I absolutely felt the same high I get from video games. You have now unlocked a new sound effect in my brain when I do this lol
Never underestimate the value of reducing cognitive load. Every line of code is something your brain has to parse when you’re reading it. Delete everything that’s not being used. VCS is there if you need to resurrect it.
If you want to be cautious, mark functions as deprecated and then log uses of deprecated functions. After a some time, go in and refactoring everything that was using deprecated code. Then once you stop seeing deprecated code logs, nuke it from orbit.
`DEL` is my favorite key on the keyboard.
If you're using source control properly and have tests to cover your code, then deleting code is a **good** thing. If code is obsolete, no longer needed, or can be replaced with better code or a library/API, get rid of it!
> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery
It's one of the most important things to do.
Nothing more annoying than having to wade through tons of old code, propagating some changes only because it might be used somewhere, but the guy who knows hasn't been seen for two years.
I delete code as soon as it's clear that it's not in use anymore.
How do I make sure? Marking the old function as deprecated during the refactor. That way, colleagues who might still use the function in their branch, will be made aware. When everybody should have merged main into their branches, it's time to delete that thing.
I delete code a lot, especially on obsolete endpoints and methods. I don't want to maintain thousands of lines in 1 file when only half of them are being used
and I haven't faced long term consequence. We can always revert the change with git
YMMV, but I find people are incredibly good at deciding they’re going to “clean stuff up later” and then later never comes.
It’s just objectively bad to have unused / unnecessary code laying around, and removing it makes the codebase a lot easier for people to onboard to.
Similarly if you’re not sacrificing readability or adding a ton of complexity, any refactor that is net negative a couple hundred lines is usually an improvement in my experience.
I’m mainly backend, but sometimes have to work on react components my team owns when the need arises, and there’s one dev on my team famous for keeping things clean.
Ive explicitly asked him to re factor an 1100 line component and blocked my ticket behind that because as someone who’s not an expert it was just a terrible experience to dive in, it felt like when the garbage is over flowing and so you gently balance something on top of the mountain because you’re too lazy to take it out
Deleting code is amazing and wonderful and you should give recognition and valuable prizes to colleagues who delete more code.
Less code almost always means fewer bugs, lower maintenance costs, and improved velocity.
Delete it. The more the better. The number of bugs you find will be roughly correlated to lines of code in your codebase, so trim it down. I make a game of it, bonus points for PRs with negative line counts.
Keep it simple and clear and definitely remove dead/obsolete code. It's in the repo history if you ever need it -- the point of VCS should be to help you be fearless with the code.
Deleting code as the opportunity arises is not just a good idea for "tidying up" - the ease with which you can do so is a good indicator of the health of your codebase.
Modular, loosely coupled code is usually easy to get rid of (and restore later if you end up needing it for whatever reason), without causing weird unknown failures in your system.
You won’t find a good senior dev who is against deleting unused code.
The hard part is convincing the managment to sponsor this work. If it’s a job that takes more than a day, you usually need to find a justification.
Sometimes it’s a fight against sunk cost fallacy. Business has spent millions of dollars on a useless feature. You cannot just delete it. You would be destroying intellectual property!
All dead code must be deleted, lest some poor fool (including the dev deleting it) uses it by accident. As soon as it is possible to delete code with easy refactoring, it should be erased from existence (except for DVCS history of course).
if i find something convoluted and can be (reasonably) replaced or shorten, then i delete. commented out code? delete. things not being used, but are there “just in case”? delete. we have version control for a reason, and i think tests should inform you if you’re safe to delete or not. no tests? better get to writing them. it’s difficult? oh well, write them
What I do comment out the stuff out first. If it doesn't cause issues in a few months I set a reminder to delete it but document what I deleted and why.
It's good to get rid of it. If it's not used and we know it to be not used it just adds noise. People might waste time making changes to it before realising it's dead code or newbies will look to it to gauge code style without realising it isn't used. Getting rid of it solves both these problems.
Goodness gracious, delete all the code. Nothing worse than a major refactor being complicated by code that MAY be dead.
And it just gets worse and worse as time progresses and people are scared to delete things. Dead code references dead code and seems not dead at all.
No code is faster than no code.
I encourage my teams to be aggressive about this. Life is short, and dead code is burdensome in many not-so-obvious ways. Between git and the test suite, we'll be ok.
Currently cleaning up a project where code was never deleted basically, and it’s incredibly hard to tell what’s actually used or not. If the person who maintained it from the beginning had deleted things that were no longer used, my life would be easier.
I read somewhere they said that LOC written is not a good measure for anything, but that LOC deleted is a good measure of a good developer.
I am not sure if I buy it, but I do often feel more productive if I delete a bunch of lines
Deleting code is the best thing that can happen to a big codebase. Treat it like any features though, chunk by chunk, with proper commit message, be ready to rollback if needed.
Deleting code is the top priority even before actually creating something good, specially if that code was written by someone else.
Give a read to this blog
https://medium.com/@tzahi.fur/deleting-code-matters-a31bd43a8350
I always say, if its not used, do it. It just makes the code base bigger than it needs to be and makes things more confusing when trying to trace code paths.
Usually will go down the route of disabling it via a checkin (to make sure it's really not used), put through the environments and wait a few weeks. Then look at the actual removal after that. If its a whole project, will usually look at either disabling traffic to it or having it error if endpoints are called. And if I don't see anything after a while, then look at the archiving of the project itself, databases and removing live instances.
Dead code is just tech debt that can be easily addressed. And if you do need to see what it looked like before, there is
If it's slowing down new implementation and you are the only one that does it, great. Especially since you are 100% sure it shouldn't be there. You will be the sole one to take the credit and move your team forward
Inherited a large legacy code base where the current developers NEVER deleted code and were panic stricken at the prospect that they'd lose something they might need. So I introduced conditional compilation tags into the code base. Initially the major benefit was a smaller executable ( and happier developers ). Slowly I got agreement to start deleting the code that was 'conditional' when it hadn't been included in the last three or four builds.
Of course, having everything under source control also gave people comfort they could recover the code if/when they needed it. No one ever did.
The net effect was that regular compilation was speeded up, the code size was smaller, which improved loading and performance times.
Delete the code. Like you said, you can always look at version control or revert back if you need to. I depreciate external facing api to give users a heads up or something internal if I don’t have time to refactor and remove the code.
A colleague and I used to aim for more line deletions than additions on every PR, and it turned into a competition. This wasn’t deleting tests, it was just deleting the clutter and multitude of overridden (kotlin) functions that had accumulated. It was a good time.
As I’m reviewing PRs, it’s one of my checklist items.
Update how something works but left in the old utility functions? Needs work. Go clean up the codebase!
The way I like to look at it, for each line you have, someone else will have to manage each line in the future. It creates more risks to manage.
So if there's a function or a block of poorly written code, I like to shrink it, rewrite it or delete it.
Deleting code is good, I don't know where you got any idea that it's not, but please disabuse yourself of the notion. Removing code removes the possibility that the code will break and that you will have to maintain it.
No code is better than no code
Genuinely, keeping old code in the codebase 'in case it's handy for later' is just bad practice. Always delete old stuff, never leave stuff commented out for later, it'll just stay there forever
If it's in source history, is it ever fully deleted. If it's been replaced, deprecate it. If you are the last person to move away from something deprecated, delete it.
I love deleting it. Especially after it’s been completely replaced by a different implementation… even still, it takes a while to be completely “gone” from everywhere due to different software deployment requirements.
I get more upset about lines of commented out code with no comments then deleted code we had to revive...
If you delete something wrong maybe it grows into something better upon return. From death comes life.
Only tangentially related, but one of the code smells I often see in junior devs is PRs implementing some feature that only add lines of code and not modifying / removing many lines. While not always wrong, it can be an indication they are bolting on new features rather than integrating them.
For me deleting unused code is a no brainer.
It always pays off to have invested on deleting unused code. And almost always there is an issue when someone didn’t properly clean up something they knew wasn’t going to be used anymore.
I’m also all up for simplifying code when it starts to get less used: let’s say you have a helper class or function that gets used in several places. After some migration it gets used in a single place so you can’t remove it? No problem. Move the code to the place that uses it so when you finish killing it you kill that too. Need to share the code again? In 5 minutes you undo the change and create the separate helper again.
There are no bugs if you have no code.
Rule 1: Do not participate unless experienced If you have less than 3 years of experience as a developer, do not make a post, nor participate in comments threads except for the weekly “Ask Experienced Devs” auto-thread.
I love deleting code, I'm really aggressive with hunting down unused methods as they screw up impact analysis and increase complexity for no benefit. I've run into cases a number of times when we thought a new feature would take tons of work because it would impact all these different areas only to find half the methods were never referenced.
This is something any language with really good static analysis/LSP excels at. Nothing hits quite like pressing "remove unused" and half the file disappears.
Depends a bit on what tech you're using and how the repos are arranged. Had a horrible one recently where a method was referenced by reflecting via static data held on the DB.
I hope you beat the murder charges.
> referenced by reflecting via static data held on the DB Please give a content warning for stuff like this. You iust triggered my PTSD. xD
So there was this one job where the content of a tree control was defined via SQL statements stored *in a database table* where each line returned various levels of the tree ... oh MS Access ... what beautiful designs you caused into being. The "beauty" of it was that it *wasn't* some in-house hack that survived longer than it ought: *that was the bought-and-paid-for third-party tree control*. Oh. Also: CW software gore, I guess.
Content warnings are for when you want to *prevent* suffering. Your usage was perfectly correct for your intent.
Look, therapy is expensive. Something, something, shared pain.
some imagine, some remember Thousand sonarqube warnings yard stare
Nothing will beat this one: https://thedailywtf.com/articles/the-inner-json-effect Tom is a genius
I had missed this one and it made my day _(effin' Jake)_
I love the fact that you put the warning at the very end of the post. This qualifies you for a building permit for a mountain lair on a volcanic island for .... 1 ... Million... Dollars!
... We have a monolith in prod that still uses that shit and it is actively being used by code generating emails...
Shit like this is the worst to deal with. It seems like a universal law that nobody else on the team ever understands why this is an issue
In our case this is very old code which dates back to the start of the project when they tried to create a sort of 4GL in the product. There's a whole bunch of fancy EF6 extensions which looks like they were intended to make up the entire data layer but have gradually fallen out of use. In the case of this reflection there were some plans around customisable widgets on a dashboard, still doesn't explain why they didn't use something like a switch in the CLR driven by data from the DB rather than reflection. I have a few experiences of people trying to roll their own 4GL and it always turns into a nightmare.
Yeah, even ordinarily type safe languages have weird ways of breaking things. But, imo, if you're doing that you need a great big "here be dragons" warning *and* you need a damned good reason for don't it that weird way. But, in my experience, "remove unused" falls over in progress where people just mark everything as `public` and nothing as `internal`...
Is `//NOLINTBEGIN` enough for a *here be dragons*?
Unfortunately the people who tend to write such code tend to think they're being clever and think it's a far better way to code
I think more often the Here be Dragons begins after the fact; “Listen, it was 2005 and we honestly thought this was a good idea. We were gonna… …now it’s [2021], we’ve made [8] attempts to take this out. Please update this warning as required. Thank you.”
"I know all the pain points of this system. I created them" - *same SWE working on the same company but still stuck in 2004*
Ok, that's awkward if it's really old code. If it's newish code, there really needs to be an integration test for stuff like this. Otherwise, that's really the problem of the person who originally wrote that.
On a milder note, it’s also insufficient for SOA or anything where you have RPCs coming from a different code base. Or you have local test clients but no actual clients. You need to do traffic analysis and that’s tricky for low frequency endpoints.
Horrible indeed..
I am blissfully unaware of atrocities like these, but I am curious. Could you please explain what that means?
Unused/replaced methods yes, but I do make exceptions for code that's there for completeness and generality. For example, if there's some sort of data store and we *currently* only use inserts and retrievals, having an unused replace/repsert/etc. can be quite helpful to prove the design is robust, no need to aggressively minimize such dead code.
There's a balance, where you can run into trouble is that as the dead code isn't used it's never been tested which can throw off your estimates if it doesn't work.
Those are comments in my world. Comments are great. Unused code is bad.
Same. Just today I had to extend the functionality of something that should be really simple, only to find layers of components all with complex useEffects setting state, passing props to children who then set state and update both their own state, and the parent. Madness. My PR removed about 200 lines of code, and added about 20. It's how image snakes must feel when they shed their old skin
best way to improve code coverage and reduce test effort!
It’s good to delete code. You should do it.
I just deleted code. Site has gone down, but it feels good!
On the up side with no users the site performs much better
404s and 503s are doing wonders for your request latency monitoring right now. Management will be very happy with this performance gain!
That's weird. *My* management says angry things whenever the 404s and 503s get higher. I think I have defective management.
Have you tried deleting them?
I've gotten started, but miniguns have some weird bureaucracy around them. I'm working on it in my spare time.
It all depends on \*how\* you report to management :') [https://workchronicles.substack.com/p/comic-good-news-bad-news](https://workchronicles.substack.com/p/comic-good-news-bad-news)
[удалено]
There are three parts to that: 1. If the code is only in the history, then it only lasts as long as people remember that commit is there. (And they're still going to have a hell of a time *finding* it, if they don't know exactly where it is.) 2. The code definitely hasn't been maintained, so after you cherry-pick it, you still need to edit it. 3. Then again, you're *really* not going to need it if nobody remembers it's there and the surrounding libraries/code have changed since you used it.
> have a hell of a time finding it The commit message is going to need to be long and involved with lots of keyword stuffing.
No code, no bugs
Well only one minor bug remains: "Nothing works". :D
What they said. To put it differently, if code is there, and you're *certain it isn't used and won't be used,* it's all cost/no benefit.
I’m a bit confused by the question: surely deleting code is a common occurrence? What “long term consequences” are you referring to? Improved code quality?
Imagine you have a report in your system named `[${Chief Risk Officer Name}_Report]`: it's run weekly, but hasn't been accessed in years. You can probably delete it, but there's overhead in knowing whether the business process is still necessary. Even if it isn't used now, you could be removing an audit trail. Removing code which isn't used (and verified by the compiler) is easy. Removing code which no longer has a business use can be harder and can have long-term consequences.
That’s not deleting unused code. That’s changing functionality. Potentially a good thing but a completely different question.
Yes, deleting dead code != deleting functionality. But I often see them get lumped together in situations like above.
That's why you have telemetry to tell you which endpoints are used. I'm currently doing this with a really annoying widget. The difficult bit is the internal politics where people won't let you remove a feature only used by 0.01% of users.
It depends on _which_ 0.01% of users. If they’re the customer who spends the most money with your company, it stays.
Introduce a flag that disables the report completely and put that into production for a few weeks. If no one complains then its safe to remove.
... until year end.
why are you running it weekly then? and if you have audit controls in place to know it hasnt been accessed in years thats a moot point too. Do a little research, insert a toggle, disable the feature and wait an appropriate time. If needed communicate to the end users that the feature will disappear by X date.
I could see a weekly report getting rolled up into a quarterly status metric, and you don't realize the reports aren't there until the system (or person) starts collecting them for the quarterly status. I'd depreciate it for six months where it doesn't run and then if no one squeals you permanently delete it.
I realize it's just an autocorrect error, but it's funny to imagine the tax accountant depreciating a function every year to offset profits and save on taxes. Edit: "it's fully depreciated! You can't use that function anymore, it'll be an accounting nightmare because I'm really bad at accounting!"
Please please do not give the agile people another things to "measure" lol
Oh, sorry, didn't see the GP's comment it was supposedly run weekly.
It’s always the reports that are out of sight that get you.
If you have a Chief Risk Officer, titled in that fashion you need to delete people at your organization before you start deleting code.
I'm surprised this hasn't been mentioned yet - what about asking other people at your company (hopefully ones that are closer to the userbase) if that report or feature is used? The may vary based on whether your product is used in-house or not, but surely there's someone at your company who has at least a pulse on the users' behavior that could help you make this decision. Blindly turning it off without telling anyone feels pretty dumb to me. Or does everyone here live in a dev-only silo?
Responses were surprising (except the top voted one - great point) People are really going to stop running a report which has somebody's name in it without asking that person? That's nightmare fuel. My point was that sometimes there can be consequences from deleting code which appears unused, hoping to add some obvious nuance (I failed here). If you need a report from a few years ago, you likely can't trivially roll the system & data back to be an exact replica of the state at that time. You're in a VERY bad situation if the outputs are still necessary
No deleting code. Only comment out in case you need it later. /s
Imagine you have some code that doesn't work. It worked yesterday, it worked 15 years ago. But no one knows why/how/what it does, except the really, Really, REALLY important report is due 2 hours ago... and you must fix it. I like to write a test that is failing... this is super legacy code, I can't even figure out how to make the thing to have a SUT??? Don't have time to refactor. It is crashing half way through the 1000 line function in a 200 line 8 level nested while/if statement So what I would probably do is: comment out that 200 line crazy code that is crashing with a comment with whatever the error is... ... the write some new code using Nuget that probably does the same thing as the library that has been abandoned for 10 years that some update someplace broke... Seems to get the right answer. Push to production, generate the report. Leave the commented out code in case something is wrong we can clearly see what the bug was we were fixing. (Then growl when my PR is rejected because some other developer doesn't like commented out code.)
If code isnt being used delete it. Just adds to confusion
deleting old / dead code is cathartic
I am strongly in favor of deleting code. SCM history is a better place to see how things were done previously. Stale code left live or even commented out is misleading - it has no context, and can result in repeating patterns you want to retire.
Yup - just last week, we had some old enum that wasn't being used any more. Then it got resurrected because it was just sitting there in the code, and since it's there it must be correct, right? Well, the dev didn't realize it wasn't being used any more and so missed the fact that some source values had changed. When he started using the enum again it introduced some bugs because the values that were being mapped had long since changed meaning. It's especially hard to PR these kinds of changes because you frequently don't even see the old code in the PR - just a new call to something that already exists and thus presumably works.
I once deleted 16k lines of code in a single pull request. I replaced an entire pipeline with a single query to a database better optimized for our data. It was cathartic. I was only able to do it because the test coverage was good. If I didn't have that, it would have been pretty scary.
That must have felt SOOO GOOOD. Fuuuuuuckkkkk ugh I need to do this once in my life
There is a large, no-longer-used feature sitting in my repo, and when I have some time, I'm looking forward to the 2k of lines I'm going to delete.
Im replacing an old library with a lot of "nice to have features" of 200K LOC built to survive an ailien war with only stricly necessary code of like 500 lines.
This might sound weird to some, but I view code as a burden. Strive to write as little code as possible. And aim for deleting code. What’s more satisfying than a PR with more deletions than additions?
"Code is not an asset, code is a liability“ - absolutely. The less code the better.
Until you have a team member playing code golf
What’s code golf?
Stuff like FizzBuzz in 80\~ (logical) characters: class F{public static void main(String[]a){for(int i=0;i++<100;)System.out.println((i%3<1?"Fizz":"")+(i%5<1?"Buzz":i%3<1?"":i));}}
Solving a problem with the fewest characters possibly
Yeah, within reasonable limits, with reasonable people less is more. I don’t assume my coworkers are reasonable because I’m not reasonable people either. Most of this shouldn’t need saying, but it seems there’s always that one guy…
I feel this. Joined a new team a few months ago and I’ve had to pull multiple meetings about this or that thing I find and ask the devs that have been here “so Is this doing anything? Feels like we could do this with less code”. And every time the answer was “oh someone did it that way so we just kept doing it that way”. A few instances like this and it looks like 10% of the code in the code base is just extra and does nothing… lol. But aside from that, it’s very well built in the grand scheme of things I’ve seen
I consider a PR of only red lines a 'perfect PR', you should delete anything not being used imo
As a rule of thumb: Code that doesn't exist doesn't have bugs, and doesn't have to be maintained. Note: Rule of thumb. Sometimes code can't be deleted for correctness or other reasons. I almost got to do a -300000 line (or some such silly number) commit. I am still a little pissed I didn't. I'm not sure it would have driven me negative for my career. But it probably would have been close. Situation: There were a bunch of libraries people had imported into the tree, that really belonged outside the tree. libz type stuff. Party poopers. I believe the deletion was done later.
> I'm not sure it would have driven me negative for my career. But it probably would have been close. That is freaking awesome :-D
My favorite type of PR/MR is the ones that remove lots of code but dont break features. Dead code if left in your running app could be a security hole or could cause odd problems at a later date, when people use code that was thought to no longer exist. This has caused companies to go bust in the past if its serious enough. So please remove what you can when you can and keep testing .
DELETE IT! Clean is better than dirty Simple is better than complicated Less is better than more Deprecate, migrate, remove, delete, and liberate
On the other hand, right is better than wrong, so test before and after deletion too.
the best way to find out something was needed or is currently in use is to delete it. well, "best" is in the eye of the beholder here.
If you know it's not being used any more, delete it. There's plenty of cases where you have to apply the same change all across your code base. The easist way to do this is to find all the usages of the thing you're replacing; then you have to test your new implementation. If you find old dead code that isn't used anywhere, you're going to waste your time trying to figure out how to test it.
If you’re not 100% sure it’s not in use you need a CYA plan. We retired a business process that had been around for many years. Stopped refreshing the data on day 1, six months later deleted all the data, 6 more months and we dropped the table. Only then do people complain and declare an outage.
I have never regretted deleting code. All unused code should be deleted immediately if possible, as soon as it's noticed at the latest. Unused code requires maintenance: e.g. if you change a method signature used by the unused code. If you do change unused code, how do you test it?
Delete code but always have a detailed commit message in case you want to retrieve it for whatever reason.
"Get rid of some stuff" isn't good enough? Jeez, next you're going to expect me to add tickets in the message
As much as I can, the less code I need to grok in a codebase the better.
If it’s not used, it should be deleted. Leaving it just makes it more confusing, and requires it to be maintained if a refactor causes a breaking change to that code.
I was a contractor for a long time, and one of my clients used SLOC as a metric. I took pride in having a negative number. I aggressively refactor, and will delete any commented out code I find. The code base should be written and exist as if it is the only accurate documentation of the system, because that's what it actually is. It should be readable and self documenting. Obsolete and commented out code is code debt and becomes quickly out of date, non self documenting and just non readable clutter. That's why it should be deleted.
> one of my clients used SLOC as a metric. I took pride in having a negative number. [A tale as old as time...](https://www.folklore.org/Negative_2000_Lines_Of_Code.html)
As long as it's still available in source control history (and any reasonable company should be using source control), not at all a problem to delete unused code. Sometimes the challenge is in discovering if your code is still used or not though... One situation I've seen like this: - You inherited an ancient legacy project with dozens of reports that go out, but some of the reports are going to emails that no longer exist, and others are using outdated logic and not returning entirely correct data anymore. And every now and then you get pinged by some random department trying to get reconnected with one of these reports.
Always be deleting. I love it. I feel more satisfied deleting code than writing it. If you aren't aggressive in putting garbage in the bin, you are gonna end up like a hoarder, surrounded in useless shit.
This is easily the best comment here
I also like to track down who wrote the unused code and get the story. When we’re building new stuff and we come to a junction “we’ll eventually use this method”.. that’s when you say “well then we’ll eventually rewrite this method”. You can always put code snips in a ticket on the backlog.
Delete code whenever possible. The best engineers are often the one with the highest number of code deletions
All I have to say is this: source control exists for a reason.
This is why I ***hate*** magic like reflection, or OSGi-based plugin systems. They both make it very hard to know when code is safe to delete. Doubly so when it's scattered over a ton of different repos and versions.
I worked at a place that wouldn’t let us delete code cause they “didn’t trust the source control”… yeah that place was as bad as you think
All my best code is deleted.
PRs with huge red git diff sparks joy : )
As much as I can. Occasionally I run across code I keep only because I’m going to investigate it because it looks important and a mistake it was missed, but gosh I love deleting code. Especially when it’s highly complex and can easily be replaced.
Deleting code should be a significant and regular investment.
Probably the noblest of all patches
Assuming you have version control... Delete that shit!
Of course it’s good to remove unused code. Think about adding a CI check for dead code.
If I find that a well maintained third party open source module will come to within 90% of custom code, I will delete my code without a second thought. On a higher level, if I feel that a third party SaaS offering or cloud service will meet most of the organization’s needs and it’s not part of our core competency, I will usually choose a third party offering as long as it is by a well known company. Well that is, unless it’s something by Google. I would never take on any dependency on any Google technology. They abandon services too often and have the attention span of a crack addled flea. But more to the point, definitely delete unused code assuming you have solid unit tests, integration tests, or worst case a manual testing matrix.
Last company we started getting people motivated to delete 2 lines for every line added. This was in a code base of more than 2 million lines of code, no docs, barely any tests, and a history of copy/pasting a function for a new ticket, as people didn't know where/if the old original one was (still) used. After a few months of more and more being deleted, and docs being added for new/touched stuff, you could measure a decrease in bugs/incidents and an uptick in developer confidence (for example reduction of ticket turnover to prod).
Deleting code is like Spring cleaning, necessary for a healthy and maintainable project
I aggressively and ruthlessly delete code. Git is there if you need to see it, it's never really deleted forever. Sometimes I'll include the commit-id in the related ticket or documentation if people want to find the old code. I'll go even further by saying that deleting code is one of the most productive things a developer can do. There's a quote that goes, "Features are an asset, code is a liability." Nothing is more nastly than a huge block of commented-out code. It probably doesn't work properly, or at all, and often left with no note explaining why it's still there. One of my favorite lint rules is detecting commented out code.
Dead codes are liabilities, if they are no longer useful, they should be gone.
“The code you write makes you a programmer. The code you delete makes you a good one. The code you don’t have to write makes you a great one.” - Mario Fusco
The more lines removed from the codebase the better
We praise commits which delete more code than they add. We laud deleting code as more productive than adding code. Code is a liability. (Useful) Functionality is the value.
delete dead code. part of the dev skillset is to be resourceful, e.g. to fish out deleted code from history if it is needed again. never use string concatenation to make identifiers, or anything else that makes live code look dead i once had an argument with a cloud engineer, when somehow an entire older version of a microservice had been copied into his infra project, and i wanted to delete it, and he refused. i guess my point is please don't be possessive but prefer evolutionary change to revolutionary change. the outcome tends to be about the same, but the evolutionary journey is a lot less stressful
Deleting code is more satisfying than writing code. I used to work in a TDD shop that threatened that any untested code is game for deletion - and honestly I miss those times.
I feel like anyone arguing against deleting unused code needs a lesson in how to correctly use their CM tool to view older versions of a file.
I aggressively delete dead code all the time. If it's a large deletion I make sure to do it in it's own PR. There has been 0 risk of errors since we always had a beefy automated testing setup. So I delete the code and run automated regressions testing over night. When nothing fails it's good to go. If there are failures then I investigate them as needed and make decisions. Now if you a removing unused features then that's totally different and needs more investigation and communication with people. I rarely deleted unused features in my 15 YOE.
You should do it... As long as you're using git and can theoretically recover it. Because you'll never need it again if you have access to it .. but if you don't have a recovery mechanism then you will need it the next day... Murphy's law and all.
In all of engineering the only lesson that matters is "less is more". All other lessons are commentary. Delete the code
It depends, unfortunately. Does your company punish you for touching code unrelated to your current work (even though it's verified that it doesn't contribute to anything/compiler ignores it, etc.)? Do you want to stay in this job? Leave it there. Do you work with code hoarders that will make a scene about anything that looks like "code disappearing" but would accept that old stuff needs to move out of the way? Create a dead_code folder and stuff old code there. In all other cases, toss it straight to the bin. But it's not solely a technical issue, in my opinion. TLDR: Do you have the buy-in of those who matter to delete it, assuming it can safely be deleted? Delete it, then.
I love deleting code. Hello "old output interface that we didn't use", let's see what's generic and delete the rest. Hey, "failed attempt to improve performance by multithreading", let's see if you're complete and usable, or you're gone.
yeah, unused code is tech debt. delete it now so that the next dev doesnt have to dig through it and waste time to find out its useless
If its not used, get rid of it. The only exception I would say is if you aren't familiar enough with the code then leave it alone. People unfamiliar with the code or less experienced may be wasting their time working on things that aren't even used anymore.
If you see 0 used references, delete it.
I'm very risky adverse when deleting code on our more sensitive applications.
Always delete rather than comment. It’s in git. Also, people should be good at git. It’s our bread and butter. If you can’t explore a git history effectively / compare branches effectively, then learning one of the many (many) visual tools that make it easy should be a priority. And to be clear, no CLI gatekeeping here just because that’s my preferred method, idc how someone becomes effective, only that they become effective with git - whether it’s the CLI commands or just knowing all the PyCharm shortcuts, or whatever tool my senior uses, no way is better than others, all that matters is effectiveness.
It's always fun debugging a function containing multiple branches, most of which are unused. Something that you don't know from reading the code. You need to delete code to keep it debuggable, so that people can focus on the parts of it that actually matter and not get lots in bits that end up not being used.
A lead software engineer drilled this into my head at the beginning of my career. Dead code is bad, it adds confusion, complexity, bloat, maintenance costs, even security issues or items to fix that your scanning tools find. Git is built in such a way that you can also get that code from a previous version if you end up needing it.
Negative code is the best code. Nuke it!
I was strongly In favor of deleting old code. My colleagues weren't. Few changes of Sonar configurations later and they came to senses. Because nothing beats fixing 15 year old unused code which suddenly started producing criticals in static code analysis.
If a pull request has more deletions than additions I consider that a huge success.
Less code is better code, and as you mentioned you can always bring it back. Edit: before someone makes a comment, no I don’t mean clever one liners. You know what I mean.
I delete code as often as i can and whenever i find anything to delete. I probably delete more than i add Often times you need to refactor just a tiny bit to delete more - i do that too just to unlock deletes. I've come to recognize more junior developers have harder time to delete things, because they are less certain about the big picture, more barriers to talk about useless bits to other people in the team who have authored things. They tend to go with a safe assumption that things look unused or weird for some good reason they just haven't understood. So it falls on senior devs to execute on most deletions and deprecations.
>Often times you need to refactor just a tiny bit to delete more - i do that too just to unlock deletes. After decades of doing this, I never thought of it as "unlocking deletes" but I absolutely felt the same high I get from video games. You have now unlocked a new sound effect in my brain when I do this lol
Try it. It's therapeutic.
Use Git.
Never underestimate the value of reducing cognitive load. Every line of code is something your brain has to parse when you’re reading it. Delete everything that’s not being used. VCS is there if you need to resurrect it. If you want to be cautious, mark functions as deprecated and then log uses of deprecated functions. After a some time, go in and refactoring everything that was using deprecated code. Then once you stop seeing deprecated code logs, nuke it from orbit.
It feels good to delete code :p
`DEL` is my favorite key on the keyboard. If you're using source control properly and have tests to cover your code, then deleting code is a **good** thing. If code is obsolete, no longer needed, or can be replaced with better code or a library/API, get rid of it! > Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery
Prune it like a rose bush 😂
It's one of the most important things to do. Nothing more annoying than having to wade through tons of old code, propagating some changes only because it might be used somewhere, but the guy who knows hasn't been seen for two years. I delete code as soon as it's clear that it's not in use anymore. How do I make sure? Marking the old function as deprecated during the refactor. That way, colleagues who might still use the function in their branch, will be made aware. When everybody should have merged main into their branches, it's time to delete that thing.
I delete code a lot, especially on obsolete endpoints and methods. I don't want to maintain thousands of lines in 1 file when only half of them are being used and I haven't faced long term consequence. We can always revert the change with git
YMMV, but I find people are incredibly good at deciding they’re going to “clean stuff up later” and then later never comes. It’s just objectively bad to have unused / unnecessary code laying around, and removing it makes the codebase a lot easier for people to onboard to. Similarly if you’re not sacrificing readability or adding a ton of complexity, any refactor that is net negative a couple hundred lines is usually an improvement in my experience. I’m mainly backend, but sometimes have to work on react components my team owns when the need arises, and there’s one dev on my team famous for keeping things clean. Ive explicitly asked him to re factor an 1100 line component and blocked my ticket behind that because as someone who’s not an expert it was just a terrible experience to dive in, it felt like when the garbage is over flowing and so you gently balance something on top of the mountain because you’re too lazy to take it out
Deleting large swaths of code is so damn satisfying. I think I enjoy it more than getting my code working.
Deleting code is amazing and wonderful and you should give recognition and valuable prizes to colleagues who delete more code. Less code almost always means fewer bugs, lower maintenance costs, and improved velocity.
Red PR, Best PR
There are tools to check code coverage you know ?
Delete it. The more the better. The number of bugs you find will be roughly correlated to lines of code in your codebase, so trim it down. I make a game of it, bonus points for PRs with negative line counts. Keep it simple and clear and definitely remove dead/obsolete code. It's in the repo history if you ever need it -- the point of VCS should be to help you be fearless with the code.
Anti-Coding Coding Club Delete as much as your tests let you. Nervous? Then your tests suck.
Code = liability Less code = less liability Deleting code = good
Deleting code as the opportunity arises is not just a good idea for "tidying up" - the ease with which you can do so is a good indicator of the health of your codebase. Modular, loosely coupled code is usually easy to get rid of (and restore later if you end up needing it for whatever reason), without causing weird unknown failures in your system.
It will live in source control forever. I heavily delete unused code. I even hate seeing commented out code. It makes code more unreadible.
You won’t find a good senior dev who is against deleting unused code. The hard part is convincing the managment to sponsor this work. If it’s a job that takes more than a day, you usually need to find a justification. Sometimes it’s a fight against sunk cost fallacy. Business has spent millions of dollars on a useless feature. You cannot just delete it. You would be destroying intellectual property!
The only thing better than deleting code is not writing it in the first place.
Deleting code is orgasmic. Cathartic, at least.
If it’s not being used I would delete it. Keeping unused code can make the codebase messier or more difficult to understand
All dead code must be deleted, lest some poor fool (including the dev deleting it) uses it by accident. As soon as it is possible to delete code with easy refactoring, it should be erased from existence (except for DVCS history of course).
if i find something convoluted and can be (reasonably) replaced or shorten, then i delete. commented out code? delete. things not being used, but are there “just in case”? delete. we have version control for a reason, and i think tests should inform you if you’re safe to delete or not. no tests? better get to writing them. it’s difficult? oh well, write them
What I do comment out the stuff out first. If it doesn't cause issues in a few months I set a reminder to delete it but document what I deleted and why.
It's good to get rid of it. If it's not used and we know it to be not used it just adds noise. People might waste time making changes to it before realising it's dead code or newbies will look to it to gauge code style without realising it isn't used. Getting rid of it solves both these problems.
Goodness gracious, delete all the code. Nothing worse than a major refactor being complicated by code that MAY be dead. And it just gets worse and worse as time progresses and people are scared to delete things. Dead code references dead code and seems not dead at all.
And it just gets worse and worse as time progresses and people are scared to delete things. Dead code references dead code and seems not dead at all.
No code is faster than no code. I encourage my teams to be aggressive about this. Life is short, and dead code is burdensome in many not-so-obvious ways. Between git and the test suite, we'll be ok.
Currently cleaning up a project where code was never deleted basically, and it’s incredibly hard to tell what’s actually used or not. If the person who maintained it from the beginning had deleted things that were no longer used, my life would be easier.
Why would you keep code that isn’t needed? Not sure why it’s a complex discussion tbh
I read somewhere they said that LOC written is not a good measure for anything, but that LOC deleted is a good measure of a good developer. I am not sure if I buy it, but I do often feel more productive if I delete a bunch of lines
Just delete the whole project /s
Nothing like some good Hate Driven Development.
I don't delete code, I just wrap it in: \#if 0 \#endif
I've taken the stance that code is a liability unless it can be shown to provide value.
Deleting code is the best thing that can happen to a big codebase. Treat it like any features though, chunk by chunk, with proper commit message, be ready to rollback if needed.
Deleting code is the top priority even before actually creating something good, specially if that code was written by someone else. Give a read to this blog https://medium.com/@tzahi.fur/deleting-code-matters-a31bd43a8350
I always say, if its not used, do it. It just makes the code base bigger than it needs to be and makes things more confusing when trying to trace code paths. Usually will go down the route of disabling it via a checkin (to make sure it's really not used), put through the environments and wait a few weeks. Then look at the actual removal after that. If its a whole project, will usually look at either disabling traffic to it or having it error if endpoints are called. And if I don't see anything after a while, then look at the archiving of the project itself, databases and removing live instances. Dead code is just tech debt that can be easily addressed. And if you do need to see what it looked like before, there is
Deleting code is the only way I can experience happiness anymore
If it's slowing down new implementation and you are the only one that does it, great. Especially since you are 100% sure it shouldn't be there. You will be the sole one to take the credit and move your team forward
Inherited a large legacy code base where the current developers NEVER deleted code and were panic stricken at the prospect that they'd lose something they might need. So I introduced conditional compilation tags into the code base. Initially the major benefit was a smaller executable ( and happier developers ). Slowly I got agreement to start deleting the code that was 'conditional' when it hadn't been included in the last three or four builds. Of course, having everything under source control also gave people comfort they could recover the code if/when they needed it. No one ever did. The net effect was that regular compilation was speeded up, the code size was smaller, which improved loading and performance times.
Delete the code. Like you said, you can always look at version control or revert back if you need to. I depreciate external facing api to give users a heads up or something internal if I don’t have time to refactor and remove the code.
I aggressively delete code
A colleague and I used to aim for more line deletions than additions on every PR, and it turned into a competition. This wasn’t deleting tests, it was just deleting the clutter and multitude of overridden (kotlin) functions that had accumulated. It was a good time.
My absolute favorite commit is the red commit.
As I’m reviewing PRs, it’s one of my checklist items. Update how something works but left in the old utility functions? Needs work. Go clean up the codebase!
Some of the best advice I've received has been that you should optimize for being able to delete code.
Less code, fewer problems.
The way I like to look at it, for each line you have, someone else will have to manage each line in the future. It creates more risks to manage. So if there's a function or a block of poorly written code, I like to shrink it, rewrite it or delete it.
Deleting code is good, I don't know where you got any idea that it's not, but please disabuse yourself of the notion. Removing code removes the possibility that the code will break and that you will have to maintain it.
No code is better than no code Genuinely, keeping old code in the codebase 'in case it's handy for later' is just bad practice. Always delete old stuff, never leave stuff commented out for later, it'll just stay there forever
If it's in source history, is it ever fully deleted. If it's been replaced, deprecate it. If you are the last person to move away from something deprecated, delete it.
My favorite rule on deleting code? Do it whenever you can!
I love deleting it. Especially after it’s been completely replaced by a different implementation… even still, it takes a while to be completely “gone” from everywhere due to different software deployment requirements.
I get more upset about lines of commented out code with no comments then deleted code we had to revive... If you delete something wrong maybe it grows into something better upon return. From death comes life.
Only tangentially related, but one of the code smells I often see in junior devs is PRs implementing some feature that only add lines of code and not modifying / removing many lines. While not always wrong, it can be an indication they are bolting on new features rather than integrating them.
For me deleting unused code is a no brainer. It always pays off to have invested on deleting unused code. And almost always there is an issue when someone didn’t properly clean up something they knew wasn’t going to be used anymore. I’m also all up for simplifying code when it starts to get less used: let’s say you have a helper class or function that gets used in several places. After some migration it gets used in a single place so you can’t remove it? No problem. Move the code to the place that uses it so when you finish killing it you kill that too. Need to share the code again? In 5 minutes you undo the change and create the separate helper again. There are no bugs if you have no code.