Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Are the Unwritten Rules of Deleting Code?

samzenpus posted about a year and a half ago | from the best-practices dept.

Programming 384

Press2ToContinue writes "I came across this page that asks the question, 'what are the unwritten rules of deleting code?' It made me realize that I have seen no references to generally-accepted best-practice documents regarding code modification, deletion, or rewrites. I would imagine Slashdot's have come across them if they exist. The answers may be somewhat language-dependent, but what best practices do Slashdot's use when they modify production code?"

cancel ×

384 comments

Sorry! There are no comments related to the filter you selected.

How can ... (0)

Anonymous Coward | about a year and a half ago | (#42501983)

one unwrite that has which been deleted?

Re:How can ... (5, Informative)

ChunderDownunder (709234) | about a year and a half ago | (#42502015)

version control.

Re:How can ... (5, Insightful)

hobarrera (2008506) | about a year and a half ago | (#42502853)

Indeed, version control is the only real solution.
We use git at work, and some coworkers insist on "commenting out" code that's no longer needed. I insist that we should delete it. Should we ever need it again, we have version control; and with proper commit messages, old code is easier to find too.

The more..... (5, Insightful)

phantomfive (622387) | about a year and a half ago | (#42501987)

The more you can delete, the better.

Re:The more..... (5, Informative)

rwven (663186) | about a year and a half ago | (#42502111)

Yeah, I have no qualms about deleting code. There are others I've seen who just comment out massive blocks of code and leave them there....for me to eventually find and delete myself, apparently. Version control is there for a purpose. If you need something back...it's there.

Re:The more..... (5, Insightful)

wmac1 (2478314) | about a year and a half ago | (#42502245)

I comment the code and leave it there for at least one minor version. If things are all right, I'll remove them. The code is in source control anyway.

Re:The more..... (5, Insightful)

mwvdlee (775178) | about a year and a half ago | (#42502339)

Why not just delete it right away? Commenting out code in version control just creates more changes.

Re:The more..... (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42502491)

If everyone uses the system "comment out first, remove after it has shown to work", seeing commented out code means that the code is still being reviewed. That might be valuable information.

Re:The more..... (5, Interesting)

Pieroxy (222434) | about a year and a half ago | (#42502521)

Once it's not in the file anymore it's out of your attention span. Leaving the code there for a revision or two allow anyone looking into the file to be instantly aware that something has happened very recently, which is usually what the person is looking for.

Depending on your language, putting a "TODO" marker allows for easy and quick cleanup afterwards.

Re:The more..... (1)

hobarrera (2008506) | about a year and a half ago | (#42502861)

Once it's not in the file anymore it's out of your attention span. Leaving the code there for a revision or two allow anyone looking into the file to be instantly aware that something has happened very recently, which is usually what the person is looking for.

If this is your goal, then you should just practice code-review of every commit and that'll achieve the same goal.

That's what I do too, (2)

jlehtira (655619) | about a year and a half ago | (#42502589)

most of the time I want to delete old code when I've written something newer to replace it. I keep the old code there for easy reference, until I'm confident the new code works at least as reliably as the old one.

Re:That's what I do too, (1)

iapetus (24050) | about a year and a half ago | (#42502845)

That's what the tests are for, surely? :D

Re:The more..... (1)

paulatz (744216) | about a year and a half ago | (#42502255)

The more you can delete, the better.

Starting from the Murphy's law on programming:
Every non trivial program has at least one bug

You can derive by rigorous analogy the Murphy's law on not-programming:
Every non written code has exactly zero bugs

Re:The more..... (0)

Anonymous Coward | about a year and a half ago | (#42502477)

If a non-trivial program has at least one bug, we can prove by induction it has infinite bugs.

Re:The more..... (1)

beelsebob (529313) | about a year and a half ago | (#42502649)

How so? A non-trivial program can't have the bug removed without shrinking the non-trivial program. At some stage it will become trivial, so in fact you can prove it has finite bugs.

I have a great idea (4, Funny)

Chrisq (894406) | about a year and a half ago | (#42502653)

The more you can delete, the better.

Starting from the Murphy's law on programming: Every non trivial program has at least one bug

You can derive by rigorous analogy the Murphy's law on not-programming: Every non written code has exactly zero bugs

I have it - the holy grail, the key to bug free coding. If the deleted code has no bugs just restore the deleted lines and delete the rest. You will then have bug free programs.

Re:The more..... (5, Insightful)

Marxdot (2699183) | about a year and a half ago | (#42502391)

"It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" --Antoine de Saint Exupéry

That is the only rule of deleting code; if you can take it away or do it more simply without causing Bad Things, do it.

Your VCS should manage this (2)

symbolset (646467) | about a year and a half ago | (#42501991)

Delete away! It's not like legacy versions aren't available. Most code should be deleted. Almost all production code is bad.

Re:Your VCS should manage this (5, Insightful)

myurr (468709) | about a year and a half ago | (#42502089)

Revision control is just one aspect. If you aren't the only person working on the code, or if there are other external dependencies such as you publish an API that others depend upon, then some form of automated testing will help ensure you haven't broken anything by deleting that code. Heck even if you are the sole developer then automated tests are still an incredibly good thingl.

If you are deleting code within a larger project then try deprecating the code first. Flag it as deprecated in the documentation (you do have documentation don't you?) and put log messages in the code that warn whenever it is called. After a while you can be confident that it is unused (or only used in obscure rarely called functions) and you can delete with confidence.

Revision control is your safety net, your last line of defence if you erroneously delete code that is in fact needed. It also allows you to always refer back to that code. Good commit messages will also help.

Re:Your VCS should manage this (1)

angel'o'sphere (80593) | about a year and a half ago | (#42502191)

Most IDEs allow you to select the method/function with that code and display a call graph. So log messages are the most useless idea ...

Re:Your VCS should manage this (3, Insightful)

LordLucless (582312) | about a year and a half ago | (#42502235)

Let me know how well that goes for you when your IDE tries to generate a call graph including third party applications that interface with yours via an HTTP API.

Re:Your VCS should manage this (0)

Anonymous Coward | about a year and a half ago | (#42502299)

Or try languages like JavaScript or python. You don't even need any external dependencies in those languages. Your own code might do some dynamic runtime crap that no IDE in the world will tell you about. Heck that's even true with java, where the IDE can usually tell you everything. But start doing dynamic runtime evaluations and you are out of luck.

Re:Your VCS should manage this (0)

Anonymous Coward | about a year and a half ago | (#42502533)

Which. Is. Why. I. Hate. Dynamic. Typing.

Makes it really easy to hack code. Makes it really hard to not end up with errors being caught in production in obscure and overlooked corner cases which statically typed languages would have caught in compilation.

Quantity vs. Quality.

Re:Your VCS should manage this (1)

angel'o'sphere (80593) | about a year and a half ago | (#42502445)

That goes superb.

There is no difference wether my function is called by another low level function or by an HTTP endpoint, or do you believe an external system can call my function "just so"?

Re:Your VCS should manage this (1)

White Flame (1074973) | about a year and a half ago | (#42502249)

That's a useless assumption when dealing with dynamically loaded/dispatched code, or editing library code that will be pulled in by multiple projects. Logging always shows what's actually in use during a run.

Besides, if you break the static call graph, the compiler will complain anyway. No need to graph.

Re:Your VCS should manage this (1)

angel'o'sphere (80593) | about a year and a half ago | (#42502431)

or editing library code that will be pulled in by multiple projects.
When you can not make sure the code is not used anymore then imho there is no reason to delete it.

Besides, if you break the static call graph, the compiler will complain anyway. No need to graph.
What is that supposed to mean? The compiler complains because a method/function is no longer called? That is new to me.

Re:Your VCS should manage this (1)

uncqual (836337) | about a year and a half ago | (#42502545)

The problem usually isn't that the entire procedure is unused (that's fairly easy to catch). Usually it's that some chunk of the procedure "appears" to be unreachable because callers should no longer (or perhaps ever should have) invoke(d) the procedure with parameters and state that causes the code in question to be executed.

Re:Your VCS should manage this (0)

Anonymous Coward | about a year and a half ago | (#42502633)

other external dependencies such as you publish an API

You should be free to delete anything you like within your code, preserved in VCS as long as you maintain all required API functionality. If it means an actual change to the API then that then becomes a higher level design decision and the system designer (whether that be yourself, a higher up or your team) then needs to look at the impact of that.

Many C libraries generally handle this by marking an interface deprecated (there's a flag you can set that gives compile-time warnings as a result). You maintain the functionality for some time (say a couple of years) then remove the function, by which time you've given plenty of people to move to the newer API.

Re:Your VCS should manage this (0)

Anonymous Coward | about a year and a half ago | (#42502099)

The article is mislabeled. It's really about rewriting, not deleting.

Revertable (2)

hism (561757) | about a year and a half ago | (#42501993)

what best practices do /.'s use when they modify production code?"

Should be able to easily revertable

Re:Revertable (4, Interesting)

gagol (583737) | about a year and a half ago | (#42502027)

When in doubt, comment out and document. I also like to keep a commented (disabled by comments) generic version of a function if I have to work a heavily optimised version. For future generations, and keep sanity when code is revisited.

Re:Revertable (1)

Anonymous Coward | about a year and a half ago | (#42502081)

When in doubt, sort it out!
Commented out code has the potential for making ruin! If your not sure about something, don't push that uncertainly into someone elses hands.

Re:Revertable (2)

serviscope_minor (664417) | about a year and a half ago | (#42502787)

I try to keep an uncommented version.

In debug mode, the optimized one will call the simple one and check the results are equal.

Doesn't work easily in all cases if the function erforms mutation though.

Version Control Is Your Friend (4, Informative)

Marillion (33728) | about a year and a half ago | (#42502003)

I really like git, but the key thing is to keep revision history. Deleted code is then never "deleted" it's just no longer cluttering up the screen. Of course it does mean you need to actually learn how to use a version control system beyond blind forward checkins.

Re:Version Control Is Your Friend (1)

Anonymous Coward | about a year and a half ago | (#42502189)

version control is necessary, but if it isn't backed up regularly, it can be worse than worthless, offering a sense of security it may not provide. Offsite backups of your version control repository is critical. Or when the server room catches fire, all you'll have is whatever code was checked out at the time, if the workstations survive at all.

Re:Version Control Is Your Friend (3, Informative)

LordLucless (582312) | about a year and a half ago | (#42502251)

With modern distributed VCSs, like git, or mercurial, every clone is a repository. That's not to say backups aren't important, but if you've got your clone on your laptop, then you'll have lost nothing except what's been committed since the last time you pulled down the codebase.

Re:Version Control Is Your Friend (1)

Anonymous Coward | about a year and a half ago | (#42502323)

Not true with git. You can restore your repo from any of the checked out copies... And except with a one man show, you probably have multiple people that checked out the code. Just make sure the dev workstations don't burn down with the 'server' under the lead devs desk ;)

Re:Version Control Is Your Friend (4, Insightful)

Anonymous Coward | about a year and a half ago | (#42502253)

Version control is not your friend when you use it like this. It becomes your worst fucking enemy.

Unless somehow your version control system somehow magically achieves the ability to imbue the knowledge of all the things that you tried and failed, and why they failed.

If you don't want the older, now obsolete and/or broken code to be seen.... get a proper IDE with code folding. Using the VCS for this is definitely using the wrong tool for the job.

If you try something obvious, and it doesn't work, odds are very good that the next bozo to come along is going to try exactly the same thing, and the odds are that they're not going to test it as well as you did.*

You need to comment the code out, and you need to add a short explanation of why it doesn't work. E.g. // this looks obvious, but because of foo baz and kwok should never be attempted. YourName Date

Then, when the idiot next in line tries to make exactly the change you said wouldn't work, (because you know that they will), and you are told to figure out why they broke the build, when you do figure out why it's broken, you can go back in the archive, pull out your previous attempt and explanation, and then clearly demonstrate that it isn't your fault.

Version control is an archiving and accountability tool. Not something to magically hide the code until you need it, because if it that's how you use it, you'll never know that the previous version was there. Thus it fails at the most important thing code must do - communicating clearly to the programmers. And communicating what doesn't work (and why) is well over half the battle, more like 80 or 90 percent. (Yet another example of the Pareto Principle in action)

TLDR: deleting old code to hide it epic fails the DRY principle

Re:Version Control Is Your Friend (-1)

James McGuigan (852772) | about a year and a half ago | (#42502313)

Insightful

Re:Version Control Is Your Friend (3, Insightful)

mwvdlee (775178) | about a year and a half ago | (#42502379)

deleting old code to hide it epic fails the DRY principle

The purpose was not to hide code, but to delete code.
If code is no longer valid and maintained, it shouldn't still be available as if it were.

Re:Version Control Is Your Friend (3, Insightful)

Anonymous Coward | about a year and a half ago | (#42502701)

Unless somehow your version control system somehow magically achieves the ability to imbue the knowledge of all the things that you tried and failed, and why they failed.

Thats why you
a) Comment well in your code explaining the algorithm being used, which gets preserved in VCS alongside the code
b) Correctly document adding/removing functionality in the commit log

If you don't want the older, now obsolete and/or broken code to be seen.... get a proper IDE with code folding. Using the VCS for this is definitely using the wrong tool for the job.

This is about code removal (eg when refactoring, tuning etc). Not hiding.

TLDR: deleting old code to hide it epic fails the DRY principle

Quite the opposite generally. Usually when I'm removing code it's when I'm refactoring to generalise code precisely so it can be reused in multiple places. Keeping the previous code in place commented out would mean I was then repeating myself.

When I have seen code where the developer's left in all the old code commented/disabled it simply makes the code look bloated and harder to read. Especially when the code blocks have changed so the code breaks the levels of {} indentation.

You need to comment the code out, and you need to add a short explanation of why it doesn't work. E.g. // this looks obvious, but because of foo baz and kwok should never be attempted. YourName Date

Rather than leaving in bloated code which in context will probably no longer make sense, it'd be better to have the correct functioning code only and in the comments where you explain what it does if there is an obvious but non-functional solution explain there what it is and why it's not done. If anyone really wanted to look at why then they can use a VCS tool to look at the first commit where that line appeared, and thus find the previous commit with the old code (or just use the date in your style suffix).

I'm guessing your performance and thus pay/bonus is determined by the number of lines of code you have in production, rather than code quality (far harder to assess)?

Ars (0)

Anonymous Coward | about a year and a half ago | (#42502009)

3 days ago.

Delete allllllll the code!!! (1)

julianl (2771751) | about a year and a half ago | (#42502013)

Delete it, and hope to god you didn't just break something.

Source control (4, Informative)

foniksonik (573572) | about a year and a half ago | (#42502021)

Who cares? You've got source control (SC) right? And you write unit tests right? If so then new code will pass the tests. If you write some benchmarks on performance then you'll know that too.

Build early, build often, build against test coverage and you've got Continuous Integration (CI). If you've got CI and SC then anyone can write new code and it will either pass the tests or it will break the build. If it breaks the build use SC to pull that crap out.

Done and done.

Vigil (4, Funny)

Anonymous Coward | about a year and a half ago | (#42502045)

Let Vigil delete your code for you when it's wrong and must be punished.

Re:Vigil (5, Informative)

rwaldin (318317) | about a year and a half ago | (#42502247)

Ah, Vigil! What a wonderfully amusing language...

https://github.com/munificent/vigil [github.com]

But isn't a language that deletes code crazy?

No, wanting to keep code that demonstrably has bugs according to its own specifications is crazy. What good could it possibly serve? It is corrupted and must be cleansed from your codebase.

Vigil will do this for you automatically.

Vigil deleted a function. Won't that cause the functions that call it to fail?

It would seem that those functions appear to be corrupted as well. Run Vigil again and it will take care of that for you. Several invocations may be required to fully excise all bugs from your code.

Re:Vigil (1)

mwvdlee (775178) | about a year and a half ago | (#42502399)

Vigil deletes code that does not pass assertions (or "swear", as they call it).
What mechanism prevents those assertions from being wrong?

You may need to indicate that something is removed (4, Insightful)

Darinbob (1142669) | about a year and a half ago | (#42502053)

It's often good to just delete. Sometimes however I feel the need to put in a comment reminding the reader that the old functionality is gone. For example, it could say "no need to support device X here" or "input has already been validated". That's because it's not always evident to look in source code history to notice that there used to be something there.

We do have written rules (2)

eksith (2776419) | about a year and a half ago | (#42502055)

Don't necessarily agree with this, but we comment out all older code when diffs aren't used. Commented code blocks with the date and editor's name works for small projects on a very tight deadline and this makes things easier if we want to rollback. Bigger projects do use diffs.

As always, this is going to be a case of "works best for my situation", rather than just "best" method to do xyz.

From the article:

3.Is the manager/tech lead aware of the problem, and if not, why not?

Since I work on contract, I don't renew if management has a chronic unawareness problem and more often than not, the problem is people. Clueless hierarchies are a symptom of a bigger disease, the brunt of which, I'd rather not take onto my shoulders.

Re:We do have written rules (1)

egcagrac0 (1410377) | about a year and a half ago | (#42502065)

This. I don't worry about unwritten rules, I follow the written rules.

Re:We do have written rules (2)

Jorgensen (313325) | about a year and a half ago | (#42502363)

Please... Don't comment it out. If people want to see what it was like before, that's what version control is for. If you delete code, you should actually delete it.

You should give the same courtesy to others as you expect from them: When reading code, you're interested in what it does, and how it does it. Not a history lesson.

Sigh (1, Informative)

styrotech (136124) | about a year and a half ago | (#42502057)

A link to a discussion on another site that was itself a link to a discussion on another site.

I know it's easy stories, but really? Are the slashdot trolls really going to offer any unique and useful insights that Ars and Stack Overflow haven't already covered?

Re:Sigh (0)

Anonymous Coward | about a year and a half ago | (#42502087)

When I have too much faith in humanity, I go and moderate article submissions during the night. Also a good source of cheap crap and illegal pharmaceuticals. Not quite "enlarge your penis!" yet, but filled with crazy spam. I invite you to help when ever you can.

Re:Sigh (0)

Anonymous Coward | about a year and a half ago | (#42502101)

No, but then we get the opportunity to link to this discussion from another site.

Re:Sigh (0)

Anonymous Coward | about a year and a half ago | (#42502115)

Still living in 1998 perhaps?
While you can find cooks, sockpuppets and even some genuinely stupid folks here, there are not so many trolls anymore.

There are only 2 important rules (1)

OzTech (524154) | about a year and a half ago | (#42502059)

#1 Make sure your code is better.
#2 If it isn't ... Don't get caught!

Re:There are only 2 important rules (1)

93 Escort Wagon (326346) | about a year and a half ago | (#42502217)

#1 Make sure your code is better.
#2 If it isn't ... Don't get caught!

You forgot...

#3 ???
#4 Profit!

Not Possible To Say (0)

Anonymous Coward | about a year and a half ago | (#42502063)

If I posted them here, they'd be written rules. If you'd like to talk with me about them, you might be able to reach me at: 0118 999 881 999 119 7253

Seriously, it's called refactoring. If you've never heard of it you really need to learn more about your craft. There are lots of books on it. Just saying you want to modify production code instead of releasing a new version says a lot about your development skills or that I read too much into people's questions.

Re:Not Possible To Say (0)

Alex Belits (437) | about a year and a half ago | (#42502801)

Seriously, it's called refactoring.

It's called re-implementation that preserves interface. "Refactoring" is a stupid term made by stupid people who like to create new words for every trivial thing they see, because they don't realize that there is an infinite number of those trivial things, and their stupid new words pollute language.

Agile/LEAN applies here (3, Insightful)

WinstonWolfIT (1550079) | about a year and a half ago | (#42502075)

Unused code gets deleted no exceptions. If there's no client demonstrating its value, its value is zero. The reasons are obvious in systems that scale into the hundreds of thousands to millions of lines of code.The way I describe it to my teams is, Just-In-Time development rather than Just-In-Case. You can have a conceptual framework in place and fill it in on demand without committing yourself to an orthogonal matrix of features that 'might be useful'.

Clean code (0)

Anonymous Coward | about a year and a half ago | (#42502083)

Read the book Clean Code by Robert C. Martin aka uncle Bob.

and then watch the videos at http://www.cleancoders.com/

My rules for deleting code (5, Funny)

EuclideanSilence (1968630) | about a year and a half ago | (#42502123)

Ok so you are working on a team and deleting code. Here are some basic rules to follow.
1) Don't delete your boss's code. Just change all the function calls to go around it. If he asks you about it, say that someone else changed it.
2) Don't cuss out the guy who's code you are deleting until after you are done. You might have to ask him why he did certain things (unexpected library behavior etc).
3) Make sure the code you add to replace the old code is longer than what you deleted. That way, you can tell your boss that you added 'x' lines of code to the project.
4) Don't waste time unit testing your new code. Obviously if you have to replace the old code, then you are a better programmer than the last one. If the last programmer's code passed unit tests, and you are better, then obviously yours would pass unit tests too.
Any politeness the other programmer shows to you after you delete his code is not to be trusted. The code we write is pride to us, and deleting someone else's code is like seeing your coworkers girlfriend naked in the shower. Sure, it's not really your fault and you didn't really do anything bad. But expect some negative passive aggressive behavior in response.

Re:My rules for deleting code (0)

Anonymous Coward | about a year and a half ago | (#42502765)

You missed my favorite if you can get away with it. Send in the code with empty functions or completely deleted. Then add you code. That way the revision control shows that you added every line you wrote/plagiarized in place of the old code. It works great at my work they don't count deleted lines and unit tests are only done when a full build is started.

  BTW, they're putting me in-charge of a small team next week.

Paid by the line (0)

Anonymous Coward | about a year and a half ago | (#42502145)

I am paid by the line, I NEVER delete.

Tests green, checked into git? (1)

ratbag (65209) | about a year and a half ago | (#42502155)

Check your test suite covers all the functionality you want your program to have. If you're feeling paranoid, create a couple of tests that WILL fail when the undesirable code is deleted. Make sure everything is in the repo. Maybe branch/tag. Delete, repeat tests, roll-back or checkin (after deleting the canary tests added above) and move on to the next thrilling episode in your coding career.

The first sentence of the paragraph above is of cours the killer - without a full-stack suite of tests there'll always be room for doubt.

Our Rules (1)

bloodhawk (813939) | about a year and a half ago | (#42502163)

Many places have standards for deletion of code, this is of course assuming by deletion you mean completed gone not just archived in source control. Deleting old code is like deleting history, if it is not there to learn from you are destined to eventually repeat the same mistakes. We never delete code that has been live and in production, comment it out or archive it off in source control, nothing that made it through to a live system is ever under any circumstances deleted.

My rules: (0)

Anonymous Coward | about a year and a half ago | (#42502167)

1) Just delete it (do NOT comment it out)
2) Put the reason in the check-in notes

Any decent version control system + sensible test suites will take care of the rest.

Personally I can't stand it when people just comment out code. Either it is needed or not. Don't clutter up code files with useless junk...it will come back to hunt you, even in small projects.

There used to be rules ... (5, Funny)

inglorion_on_the_net (1965514) | about a year and a half ago | (#42502177)

There used to be written rules for deleting code. Then someone deleted them. And since we don't use version control, we have no way to get them back.

Clean Code (1)

Anonymous Coward | about a year and a half ago | (#42502185)

Apparantly my last post got deleted or somehow dissapeared:-(

Code refactoring is well described in the book Clean Code written by Robert C. Martin AKA Uncle Bob.
The Book contains some good examples on how to rewrite legacy code with a few wll picked hands-on examples.

He explains a multitude of "rules" for modifying and deleting code, as well as testing it.

If you want to remember his rules it is a good idea to pay for and watch the videos at http://www.cleancoders.com but it is not necessary.

Whenever the program seems a bit slow... (0)

Anonymous Coward | about a year and a half ago | (#42502193)

...I just keep deleting code until the program runs faster! When the boss sees the performance figures go up, that's tangible progress you can take pride in!

In any case, just delete lines of code at random until you observe malfunctions. If eliminating a line of code has no apparent effect, the code must be superfluous!

Version and change management. (1)

laxr5rs (2658895) | about a year and a half ago | (#42502201)

Programs like SVN, TFS from Microsoft and GIT take care of remembering all the changes, of course. That's what I do for a living. With software change management using these programs, you can write any documentation you want as you can access any part of the code at any moment in time in its history. At my place of work, we are using the Scrum development process and past code isn't really worried about too much. In a sense we are always massaging all the code in the direction of satisfying clients, and making the code work better, while keeping track, using TFS of all the described items that were worked on as time goes along. We can access any file at any time along with its associated work items. From this any sort of story can be created about the deletion of code. The usual story in a busy business is that documentation is hard, so let's just move on.

Don't break the API (1)

White Flame (1074973) | about a year and a half ago | (#42502225)

Delete whatever you want behind a well-defined API barrier, as long as it still does the job when you're done.

Delete entire unused and obsolete APIs where appropriate.

Individual function bodies count as APIs, as well as large modules.

Standard Practice (0)

Anonymous Coward | about a year and a half ago | (#42502227)

Once the developer has left the organisation, then you delete all their code.

I wouldn't delete any production code (0)

Anonymous Coward | about a year and a half ago | (#42502267)

Use version control and do your changes on development code.

I don't understand the question... (2)

Foske (144771) | about a year and a half ago | (#42502331)

Either you use VCS, and you can' t ever delete code because you use it properly. Then the answer is: You can delete whatever you like in the latest revision. If you don't use VCS you have problems that exceed the scope of deleted unused code by a factor 1000, and you shouldn't be allowed access to ANY production code.

ObBetteridge (0)

Anonymous Coward | about a year and a half ago | (#42502377)

No.

Simple 3 step procedure (1)

sidevans (66118) | about a year and a half ago | (#42502389)

1. Don't delete anything, just comment out things
2. Delete everything EXCEPT var_dumps etc (make sure the code works)
3. Write a description in comments for functions / weird crap. Delete all unused code, indent with 2 spaces.

at least if you make the code look visually nice, people think you know what you're doing.

I do PHP, sorry purists.

Same as the rules for deleting Gods (0)

Anonymous Coward | about a year and a half ago | (#42502411)

And just as hard to make it permanent ....

This comment has been deleted ... (5, Funny)

ElRabbit (2624627) | about a year and a half ago | (#42502417)

... for clarity

Go step-by-step, don't directly delete it (0)

Anonymous Coward | about a year and a half ago | (#42502455)

1. mark it as deprecated (although not every language has this option) so that nobody starts adding new calls to it

2. find any place it is used and find workarounds/replacements

3. comment it

4. After a reasonable amount of time if nobody complains that it's been commented, delete it

5. (D)VCS is your friend to revert any of the above.

Points 6. and 7. are left to the imagination (lack thereof) of other ACs and FTFYs ...

Depends (0)

Anonymous Coward | about a year and a half ago | (#42502493)

It really depends on the code itself.

But generally, if the code is still useful as a guide or reminder, I'll comment it out, and then gradually delete the comment blocks as they lost their usefulness.
If the code's useless from the get go, I'll just nuke it with holy hellfire without blinking.

Captcha: discreet

If there was *any* kind of consensus... (1)

wonkey_monkey (2592601) | about a year and a half ago | (#42502525)

...on these unwritten rules, they'd have been written down a long time ago.

Mentioning the deleted code (4, Insightful)

rollingcalf (605357) | about a year and a half ago | (#42502579)

At a previous employer, there was a *written* rule for deleting significant blocks of code.

If a properly functioning block of code already in production was being deleted due to changes in business requirements, a comment should be inserted at or near the point of deletion, which mentions that some code was deleted and the original code can be found in version x.xx, and preferably a phrase saying what it did.

However, if the code was not yet released to the production system, or was being deleted because it's buggy, it was acceptable to simply delete it without leaving a comment (if somebody needed to research an old bug they could look in the bug tracker, which would show which version of the code last had the bug, so there was no need to mention the bug-deletion in the code).

The rules (0)

tp_xyzzy (1575867) | about a year and a half ago | (#42502595)

1) Adding new code is always ok. Just need to keep it independent of the old code. Avoid modifying intersection of old code and new code.
2) Modifying code is dangerous. It can break features anywhere in the system.
3) Deleting code is extreamly dangerous. It can both break code, and lose information what was original code version.

No amount of version control hacks is changing these rules.

Re:The rules (1)

viperidaenz (2515578) | about a year and a half ago | (#42502719)

So your answer is to never change code once its written and just hack on the sides if behaviour needs changing?

Re:The rules (2)

tp_xyzzy (1575867) | about a year and a half ago | (#42502767)

It's more like breaking already tested code is wasting too much time...

The first rule (0)

Anonymous Coward | about a year and a half ago | (#42502603)

The first rule of code reuse is - the code must be worth reusing.

If you're not sure, put it in a fucking SCM & delete away.

The first rule - If only that were true. (1)

Chrisq (894406) | about a year and a half ago | (#42502685)

The first rule of code reuse is - the code must be worth reusing.

If you're not sure, put it in a fucking SCM & delete away.

If only that were true. I once worked in a team where someone had written a function which took an integer and returned the same value (they were blindly following a pattern where a converter was called stringToInt, intToString and wrote an intToInt because "other cases called a function"). Two other developers had subsequently used this function (copy/paste programming)!

ngsource is great for config/code storage (0)

Anonymous Coward | about a year and a half ago | (#42502617)

We have quite approx 20 people in our team that can be working on various things from VB Code, SQL Statements, router configs, anything text based that can be modified. We have been using ngsource for some years now and its worked very well for us http://www.ngsource.com/SourceControl.htm I'd suggest using this for the basics of version control, etc.

Re:ngsource is great for config/code storage (1)

XcepticZP (1331217) | about a year and a half ago | (#42502857)

Nothing new here that traditional, more established VCS systems can't do. Stick to SVN/Mercurial/Git. Advertise your own product much, AC?

Seriously (1)

OzTech (524154) | about a year and a half ago | (#42502639)

While RCS may be well and good, it won't necessarily show what was deleted or why.

My rule of thumb is to comment out the old stuff, and date it. If it is still there after a few months and the new stuff has been working without anyone noticing or commenting (in a negative fashion), this it's pretty safe to delete it and leave any history/archiving to RCS. Before doing the final delete, I will usually still put a comment in the function/proc header (if I hadn't already done so) about the deletion/major-change as this is more often than not the only thing that is really seen.

Simple: Don't (1)

RedLeg (22564) | about a year and a half ago | (#42502641)

If you have a version control system in place. it's not an issue cause you can roll back or at least see the previous versions.

If you're operating on a more basic level, clone the crufty code, put the cruft in comments explaining CLEARLY why you cut it out.

When you fix or replace what you cloned, comment there as to exactly what you think was wrong or broken, and how you fixed it.

One thing that is certain, with production code, you will NOT be the last person to work on it. Pay it forward with good practice.

Red

Re:Simple: Don't (1)

viperidaenz (2515578) | about a year and a half ago | (#42502715)

Pay it forward with good practice, don't comment out code. Comments are for comments, not code.

Re:Simple: Don't (1)

asdf7890 (1518587) | about a year and a half ago | (#42502851)

Commenting just code is fine for temporary testing/debugging/rewriting.

Leaving code in a commented state is a comment ("this is how something used to be done here"), but not a terribly helpful one. If you find yourself doing this, as well as commenting the code add a true comment stating why and what code replaces its function (the bit above, the bit below, something elsewhere, nothing (it is truly deprecated)?) and why.

Once some time has passed, unless the change is significant and there is a chance someone will come along and "unchange" it not knowing the history, such comments along with the commented code should be removed as it is all in source control anyway - but keeping it in your face (and the faces of other people working on the code) in the short term can sometimes be quite helpful especially in the case of code several people are actively looking at as one of them may quickly spot a flaw (which may otherwise go unnoticed for a while longer) that makes your new more clean/fast/bugless code far less perfect than you first thought.

Use Version Control!!! (1)

Big Hairy Ian (1155547) | about a year and a half ago | (#42502651)

Personally I use the "Back Space" key but I have heard of strange perverted creatures who use the "Del" key :)

Uhm delete it? (1)

viperidaenz (2515578) | about a year and a half ago | (#42502705)

Delete it. Plain and simple.
Put a comment/bug id in the commit log.
What's the problem?

The rules were simple (1)

Llian (615902) | about a year and a half ago | (#42502813)

The rules were simple for this, but they got deleted.

version control and start/end with working code. (1)

Barryke (772876) | about a year and a half ago | (#42502823)

Rewriting code?
version control + start from a working situation and end with a working situation. Where working situation means bugfree and no broken parts other than those that are going to be rewritten.

Deleting code?
version control.

Don't ask don't tell? (1)

SpaghettiPattern (609814) | about a year and a half ago | (#42502843)

Don't ask don't tell?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>