Shared publicly  - 
Ben Liebrand's profile photoChristie Jam F's profile photoAndrew Watt's profile photoSheila Richardson's profile photo
Or use a neat versioning system like the rest of the world?
Remove it. What you got reversion history for? So that management can change their mind constantly ;) .
remove it and forget it lol
+dieBeschleuniger this will give some conflicts if you are about to reorganize the whole broken structure of the grown project and some commits are between now and the point where management changes their mind
don't delete... just put it on a #define :)
That's what VCS are for. Delete it!
Ug... The code base I work on has thousands of lines of code that've been commented out, at least as far back as our CVS repository goes, May 2004... Often with a comment like "bug fix 2394" or something (not that I can tell if the code or the commenting out of the code is the actual fix).

Even better is to simply comment out calls to methods no longer used, that way future maintainers can keep maintaining the unused code without realizing it's not used unless they spend the time to check...

Or for more fun, keep the UI element that makes a reference to the code, but comment out the single line that adds the element to the screen for the user.
i thing you must not remove it until its final
I never understand the not deleting unneeded code if you are using version control. You want it back? get it from the versioning system.
If you do TDD and BDD right, there will be no comments.
The code should be written in ubiquitous language, and if deleting code fulfills the new Tests, there is no need to keep the code.

If management changes its businessrequirements back, then you're better of remodelling and coding, since entering old code into modified enviroment may have sideeffects.
Comments are for commenting, not disabling code. Furthermore, once a comment is no longer relevant it must be removed or it serves no purpose. Commented code is irelevant. The purpose of comments is to describe the code so that it can be understood by others or by you a year from now. The first reaction someone has to a commented out bit of code is confusion: "WTF is this here for?"

A properly organized RCS is the only correct way to keep old code around. Any time I adopt a codebase I put it in git and purge the comments.

Oh, and the same goes for code permanently disabled by a #define or if statement.

Don't agree? Then I hope you rot in your dead end job, because I never want to see the trash you're turning out.
Ah, but all of these theories aside - in reality now - when the management changes their minds (say over the weekend, when they've had no choice but to think about it) and decides they want that feature, it costs you nothing to un-comment it and <voila!> they're a lot happier and you're the hero. Sometimes if's foresight like this that makes life a lot easier.
Never! Trolls have to eat, too! :D
Senyo A
commenting is a life saver.....#coding
pros wrap it in a if(featureEnabled) clause, so putting it back in is a matter of seconds
Comment!!! Always!!! Management will ask for the one function that you delated. Hehe
If you see my code, most of the code is commented out because of that...
+Gene Moody Yor doin it rong.

And tests should tell you what the code does and how to use it, not comments. DELETE. You have VCS, use it.

There are hardly ANY comments in my code, yet it is readable and concise. The tests make it clear what the purpose is, and how to use it. Comments quickly become obsolete and useless, and often not updated along with the code it's self. The ONLY comments I use are //TODO: and //This is deprecated because ... or something of that sort, or if it is an exception to a general rule used elsewhere.
I always try to comment it Ha Ha
I would even say: "So let me add a parameter here for when magement changes their mind they can toogle it on/off". So typical! =)
Andre: Or at least an Easter-egg keypress combination that hides it so that you don't have to look at it when you use the software.

Another trick...hide it down a menu tunnel and neglect to document it.
+Bill Housley : ahah. i really still want to do that someday, make some key-stroke combination to start some hidden operation. Guess i'm just afraid they will fire me when they find out! :P
sean s.
Just comment it out. 's cool.
every day.... every day that's how i feel.
Isaline: An Easter egg is an undocumented, obscure combination of keystrokes that activate a hidden feature. Game builders use them all the time.
never trust management when you have that question
If you work with a versionning system => delete!!!
Otherwise, delete it! You've done it one, why couldn't you do it again?
ROFL this is so unbelievably the story of my work life!!!!! have this in EVERY project!
ha, haha! Been there done that! Comment it, time is money. And for the love of god leave a description!
+Justin Lasher Actually, adding a parameter to "toogle on/off" would spare you so much time in future when they will call you saying they want the functionality back. But hell yeah, "time is money"
My blog
Sounds like fun
Bre o
comment it out
жаба, конечно душит, выкидывать код. Поэтому я использую систему контроля версий (SVN, Git) и смело могу удалять любые строки из любого подконтрольного кода
if you're going to check it in, in code repository. Delete it.
This happens daily here. If it's not management, it's the customer.
+Gene Moody It takes about the same amount of effort to roll back to an earlier commit in git. And if you're smart, you've already implemented a system to deploy code out of your RCS. Do that and it takes even less time. The end result is management will think you're a god.

Luckily I make the decisions here, and that's the way it is.
Coding is 75% commenting out, 25% actual code lol
Only comment code if you're not using versioning. In which case, god have mercy on your soul.
Its Not a thought, After years of working with management, "always Comment Out"!.. And Date!! When you do this proves the list of changes (or circles) management has been running in..
Comment out and leave absurd comments on why it was commented out both in the code and in the repo
Use a Revision Control System, commit with a good comment then delete it.
Always comment it out. Don't throw anything away.
+Cleav Caffee Or you can use an RCS, and throw the change log in their face as solid proof of the things you had to change as a result of their flip-flopping.
Guilty. I know I should be deleting it because we have ssc but my manager always says to comment it out to keep it simpler. May the developer gods forgive me.
John F.
<!-- Always Comment -->
Haha. Sometimes i have as much commented out code as i have running code.
Ultimate dilemma. it's always wanted when it's gone. Lol
Keep it and go around it with a 'goto' statement and see how many people start giving you 'that' look.
-yeah I do that a lot- cause they will come back and say you know what...
Keep it Commented out . Put date and initial and brief reason why you comment it out.
What do is this meme tryin' to f***in' say...........!?
Yeah, I comment out some functions once in a while. Usually because management (or whomever) doesn't understand. Use some keywords in the comment block so you can easily find it again, too.
.... again. something i've done time and time again
f course.....dnt take the hard way....?
I like it when people with 2-3 years experience are so confident they are the holders of the Holy Grail of programming :)
Guys/girls, talk to you in 10 years...
sounds like something a noob that doesn't understand how to use source control would think.
Luckily (I suppose) I'm the only web designer and developer in our entire company. Everything I do just looks like Chinese to them anyhow.
Maybe some of us are trying to learn by sharing our thoughts with other coders. I guess we all can't come out of the womb with a keyboard in hand like you. Should we bow down and kiss your feet now or later?
No one likes snobby, stuck-up programmers. Good luck with that. The rest of us are going to share and learn now.
when you are assigned a project started by someone, and they used the comments option .... oh the horror
This is true I'm afraid. To be honest I hate to see commented out code but there are cases where you just know this will happen so comment out anyway.
+Cristian Easterly, I was talking about this attitude: "Don't agree? Then I hope you rot in your dead end job, because I never want to see the trash you're turning out.".
Of course everybody is entitled to an opinion and it's good to share it, because in the end you are the one making the decision and it's good to make an educated decision. I never said that everyone is wrong, I just said that I hate when unexperienced people are talking like they are the keepers of absolute truth and dismiss everyone else.
kind of like you did? listen, i'm not trying to start anything but you sort of came off as a know-it-all as well. i'm sure there was a nicer way to say what you said without crushing young (unexperienced) coders. just saying.
on a lighter note, i totally agree with you when you say you have no room for an attitude like that. i don't either. i know a lot of people that talk like that but i let them figure it out for themselves. they will eventually hit that wall where they realize they are not God of Code. you don't have to bring that wall to them and rub their noses in it.
OMG! I do that all the time. I would just comment it out until they change there mind -LOL!
+Cristian Easterly I never said that programmers with 2-3 years of experience shouldn't say what's their opinion...
I just wanted to be an irony towards the unexperienced programmers that believe they know the absolute truths of programming.
I was a beginner too and I know I had strong opinions, but I never dismissed more experienced people. I listened to their opinions and made my own choices, but I never told them they are idiots or something similar.
Anyway, I'm sorry if my comment sounded like an attempt to dismiss ALL unexperienced programmers, that wasn't my intention.
#ifdef GOOD_IDEA_1
/* good "old" Code */

Your old code ist just one "#define" away....
Ouch. that hit kinda close to home. Turns out my code is usually more comments than working code =/ On the plus side, I don't have management harassing me :D
Never forget to comment WHY (WHO´s idea it was) and WHEN it was commented out.
"Save your ass" ;-)
Ahhhhh, comments in code: a bewildering conundrum. LOL! I can tell many stories about them. One that remains fresh in my mind is the one that said “if you don’t understand why this was coded this way, call Frank at (and it gave a phone number)”. Go to find out that Frank retired about five years ago. Hmmmm. I wonder why Frank coded it that way, now we will never know. LOL! ☺
after every line of code this comes to mind!
usually just comment it out... it will be back!
Sometimes you have to cut it and paste it on notepad. Managers are bitches sometimes...
Tic Biz
Comment good work - with notes - CYA
(haven't bothered to look at the 143 comments but to my mind) the horror is that he doesn't use a decent VCS which will let him effectively do both -- delete it as well as get it back when he wants to
comment it....that what i do always :)
lol as usual comment hahaha
The correct answer is to toss the feature in question on a branch for later remerge.
Obviously no one is a perfectionist. A perfectionist would realize the code they are commenting out is outdated anyways. They would comment it out. When management wants it restored say "sorry we removed it like you had requested". Then they would try to recycle as much of it as possible when rewriting, and use the extra time they saved recycling playing browser based games. Not only are you creating workload to maintain your job, but having fun at the same time.
Using a versioning system to store the unused code and then just delete it from the main line might be a good idea if the code is not very big. You can do that by creating a branch, by tagging the last revision containing the feature, by shelving files (it's a Perforce feature, I don't know if other versioning systems have this).
However, think about a big feature, that consists of 1000s of lines of code, with various calls spread across dozens of files. It's not that easy to remerge the changes from a previous changelist, if you did lots of modifications after you deleted the code.
On the other hand, if you use a #ifdef/#else/#endif section and use the same define in all relevant files, it would be much easier to reactivate the feature if it's requested.
Of course, after a period of time (at least a few months, IMO; even better, after the software is released), if nobody wants that feature back or if the code has changed so much, that the unused code wouldn't work anyway, you can delete it.
One more argument for the #define section is that maybe the management will ask someone else to reenable the feature. If you're not around to tell him/her exactly what changelist should be remerged, it might be a pain in the back for that person.
Comment it out. If you don't need it for 9 months then delete it. :)
No, I've never thought that. THIS IS WHAT VERSION CONTROL IS FOR!
heh heh story of my uni life XD not sure about a bit of code.... Comment it out :P almost as good as turning all your variables Static XD
Remove it without a second thought + <!--------- You're Welcome -------!>
'Management' has very little to do with that. Removing the code specially after it's been debugged is like trashing valuable things. We do that only when we are sure we won't need them no more. Versioning is fine but merging with old versions is labor too. Uncommenting the code in place much simpler. It's not 'management' it's desire not to do something several times.
Happens to me all time haha
Its scary that so many relate to this. ahem! mgmt!
Versioning is a pain if the requirements flip-flop from day to day. Commenting lets you keep updating code without having to remember which version had the code you wanted. You can remove the comments when management make up their minds.

Versioning is necessary, but commenting code has its place sometimes too. We don't all live in a perfect world where VCS is flawless and management talk IT speak.
+Daniel Lupton - Sure you do. If you work with a good versioning system (Mercurial or Git come to mind), just create clones of the different repos and, as requirements change, work in whichever clone is appropriate. When management makes up their mind, push the clone that is appropriate. (And, you can extend this out for an entire team.)

Managing entire chunks of source code via commenting is not a long-term solution. (But, I do agree it's okay to do in the interim between ideas.)

As a side note - if you are coding before there are solid requirements from the stakeholders (in this case, management) then I would say the development team needs to work on their processes and buy off a bit more. (Takes a lot of work, but it can be done.)
All of my custom projects are at least double the file size they should be because of this very situation
I bet that's what's on the road ahead for me
exactly what i think most of the times.. They do really come back and change their mind!!!
Branch it on you rcs and delete it. No since keeping junk around. Keep it clean! :)
don't we all know that? One thinks, I'll just comment it out until 'they' make up their minds and then I'll remove it... Sadly neither the first nor the second step there ever seems to happen...
(I say after working on a legacy project for the past couple of weeks.. sigh)
Using a versioning system on my projects but I still catch my self in commenting stuff out, old habits?
Sometime do happen, what should we do, hard to decide sometime
This has been the case a lot of times. Reversion is hard if you made changes in between versions. Sometimes reversion would work to just get the code you need.
They will always change their minds...I have done this.
When in doubt always comment. Even Blizzard does it.
i was thinking of the colours involved. was anyone else?
Add a comment...