I have a class, which is part of a code library project that was written for a particular purpose that is no longer required. So the question is what do you do with code like this? Do you simply delete it, or do you leave it in bearing in mind that future developers may come across it and not realise that they can disregard it or do you have some sort of archive system, is there a recognised "pattern" that is in use...
+34
A:
Delete it. You can always get it back from the version control system later. You do have version control, don't you?
anon
2009-05-14 08:16:31
easy money :)
annakata
2009-05-14 08:17:52
It feels dirty saying this but... at the moment... no. I know, I know that's is REALLY bad, we're a small team (2) and it's become one of those things that we know we need to do, but it keeps getting put on the backburner because we've survived so far. Be gentle!!!
Nick Allen - Tungle139
2009-05-14 08:21:44
You can implement a basic VCS in a few minutes and the software is free. There can be no excuses for not doing so.
anon
2009-05-14 08:23:45
For what it's worth, just go and bloody do it... It'll take less than 30 minutes to install an SVN Server, and the tortoise clients on 2 dev machines. Maybe another 30 for you quickly read up on how it works. And it will save you a WORLD of head aches.
Eoin Campbell
2009-05-14 08:23:51
The less code you own, the better. Think of code as a liability: http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability (My fingers are itching to be able to remove a bunch of concurrency-related code from my project, because I've thought of a new architecture that lets me simplify the code quite much.)
Esko Luontola
2009-05-14 08:25:20
The point of course is that you're only surviving until all of a sudden you aren't. Source control is cheap and easy, you can fix this in a few hours. For want of a nail and all that...
annakata
2009-05-14 08:25:32
+1 For asking the question that really makes a difference.
Fredrik Mörk
2009-05-14 08:33:30
Honestly, there's no excuse for not having source control, small team or not. Even solo developers, even hobbyists should. There's almost no cost to it (10 minutes of time?) and the benefit when you find you need it is incalculable. You'll be doing yourself a huge favor and you'll be able to make changes more confidently.
Chuck
2009-05-14 08:35:25
Nick Allen - Tungle139
2009-05-14 08:45:18
There's really no excuse for no VCS -- although setting up VCS / CI et al can be painful.I HIGHLY reccommend Buildix from Thoughtworks - available as a VMWare appliance, and it gives you SVN / CruiseControl / Trac out of the box. Adding a new project takes literally 30 seconds.Completely removes the "too hard" argument.
Marty Pitt
2009-05-14 08:51:42
More importantly, if you don't use source control, I'll kill you. It's not personal, it's just that there's a non-zero probability that I may need to work on your codebase at some point in the future. Seriously, though, do it. At best you're being stupidly reckless and at worst you're stealing from your employer. Do it now.
Rhythmic Fistman
2009-07-08 14:21:53
A:
I try to keep my application code as little as possible. Library code should be compatible for a number of release then remove it or just mark it as deprecated.
dfa
2009-05-14 08:18:00
+13
A:
As Neil said, delete it. If I'm hired to maintain your project years after you are done with it and it's still full of dead code.. I'm gonna haunt you. And not the ooooohhhhh nice kinda haunting.. but the ARRRRWWWGGGGGRRRR!!!!! annoying kind of haunting.
Boo
2009-05-14 08:19:13
+1
A:
If it is not used anywhere, and no longer required you should delete it to avoid confusion.
You didn't say what code you are using but in C#/VisualStudio you can use the Obsolete attribute to tell other developers not to use the code, you can set the errors argument to true, and this will break the build anywhere that the code is being used.
Mark Dickinson
2009-05-14 08:19:13
+5
A:
It depends.
If it is unused because it is obsolete, I would clean it from the current code base by deleting it. If it turns out that it is in fact needed, you can always retrieve it from source control.
If it is unused at the moment, but may be used in the near future, I would keep it in the current code base as I wouldn't expect fellow developers to browse the source control for features just in case. In other words: if you delete something that has a high chance of being used, chances are that someone will re-implement it.
Brian Rasmussen
2009-05-14 08:25:04
Great answer - particularly for the second point. If the candidate for deletion makes sense as part of the interface, then it should not be deleted if there is a reasonable probability of it being useful later. Don't make someone else rewrite it. This is particularly relevant if you're working on a public-facing interface (i.e. an interface that someone else will some day be using).
Dominic Rodger
2009-05-14 08:32:25
+1
A:
I would start off by tagging the out-dated code elements with the Obsolete attribute. That way you will be able to locate any code that refers to the out-dated elements, giving you a way to update those parts. When you no longer get any compiler warnings that you use obsoleted code, go ahead and delete it.
Update: OK, now I was thinking .NET and C#, but I am sure many other languages have similar features...
Fredrik Mörk
2009-05-14 08:26:46
+1 I would tag them with @deprecated (in Java) to avoid future developers to use them, and make them think further (why to use that method, the class itself). My two cents.
ATorras
2009-05-14 08:39:52
A:
The best option is to remove the code so you have a cleaner repository. Most of the time it is just a short term fealing you delete somehting of potential enormous value. Counting on svn if fellow programmer need it later won't really work. Because you have to know the code existed before and then some has to scan through the svn. If I really think I want to keep that code than I usually make an archive out of the files and add them with a description into our wiki and then I delete the code. Over the search of the wiki someone can find the code. Scan it using the archive and as the decription contains repository and revision number they can even ressurect the parts they need easily.
Norbert Hartl
2009-05-14 08:30:04