Slashdot Mirror
What Are the Unwritten Rules of Deleting Code?
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?"
The more you can delete, the better.
"First they came for the slanderers and i said nothing."
Delete away! It's not like legacy versions aren't available. Most code should be deleted. Almost all production code is bad.
Help stamp out iliturcy.
what best practices do /.'s use when they modify production code?"
Should be able to easily revertable
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.
This is a boring sig
Delete it, and hope to god you didn't just break something.
version control.
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.
A fool throws a stone into a well and a thousand sages can not remove it.
Let Vigil delete your code for you when it's wrong and must be punished.
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.
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:
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.
If computers were people, I'd be a misanthrope.
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?
#1 Make sure your code is better. ... Don't get caught!
#2 If it isn't
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'.
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.
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.
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.
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.
Please correct me if I got my facts wrong.
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.
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.
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.
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.
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.
I'm not signing anything
... for clarity
...on these unwritten rules, they'd have been written down a long time ago.
systemd is Roko's Basilisk.
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).
---------
There is inferior bacteria on the interior of your posterior.
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.
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.
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
Personally I use the "Back Space" key but I have heard of strange perverted creatures who use the "Del" key :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
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.
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)!
Delete it. Plain and simple.
Put a comment/bug id in the commit log.
What's the problem?
Pay it forward with good practice, don't comment out code. Comments are for comments, not code.
So your answer is to never change code once its written and just hack on the sides if behaviour needs changing?
It's more like breaking already tested code is wasting too much time...
The rules were simple for this, but they got deleted.
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.
Hivemind harvest in progress..
Don't ask don't tell?
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
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.
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.
Nothing new here that traditional, more established VCS systems can't do. Stick to SVN/Mercurial/Git. Advertise your own product much, AC?
1. Not always true by a long way, especially when you're coding for devices with limited space. It can also lead to unnecessary duplication, overly convoluted logic to avoid modifying existing code, unnecessary duplication, poor performance and unnecessary duplication.
2. Bug fixes are dangerous? Really? That could have saved me a lot of time at my job before last. :D
3. If you think deleting code causes information to be lost, you need to review your source code control policies. Now. Yes, it can be dangerous to remove crufty looking old code, because it frequently contains years worth of minor fixes to deal with bizarre edge cases, device oddities and the suchlike. But you know what? Those should all be well commented in the code, and covered by appropriate tests that will ensure your new version works too. If they're not, you might need to review some other policies as well.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
No I feel you should comment it out for one version, or one iteration.
The problem with deleting code is that you lose functionality and information. Yes yes we have this ideal world where unit tests will ensure that the code only does what it is supposed to. Be that as it may, there is a reason...
Code that needs to be completely rewritten is crap code. We can argue how it came to be, but the reality is that every developer for one reason or another has created crap code. It is unavoidable. Crap code is code that does many things, but quite a bit of it incorrectly. It also is hard to get a grip on because of its complexity. For if it was easy to understand and easy to fix it would not require a rewrite, no?
Thus when you rewrite you are trying to simplify, and restructure. And because you don't have a handle of the original code you are going to introduce bugs in the new code. These bugs are new cases that you have not thought about and thus need thinking about. They are not critical bugs since the rewritten code is easy to understand and easy to fix. BUT these bugs need to be cross referenced with the original code. You need to see if these bugs are bugs, or actually the correct answer. Sometimes I was working on code and thought, "crap, the new code is right even though I thought this was a bug."
If you delete, and need to check it with version control you are adding time, effort and complexity of actions. And then instead of going back to do a cross reference you are going to introduce new bugs that can grow into weeds and cause this cycle of rewriting again.
I have found that often when I rewrite I learn new facets of my code and figure out the critical bugs. It is then I decide to stop the rewrite, and integrate the new code into the old code and fix things up. For the I see in the rewrite that the new rewritten code is going to introduce quite a bit of new code that is going to mean retesting, and assurance that things all work. And maybe this new rewritten code will not be better after all. Deleting the old code means me merging the refactored code, with the old code introducing even more complexity.
Commenting out is ugly, but it has made it easier to experimenting in a short order of time without causing version control havoc.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
There is only one rule -- don't replace better code with worse code.
Contrary to the popular belief, there indeed is no God.
Follow your software design criteria and your design documents, then it should be clear. One should not simply sit down and hack away changes without careful planing.
That's what I tell my team time and again. Do NOT simply use the IDE to comment code out. Delete it!
If the code was replaced due to a change then the old one wouldn't work anymore anyway. If the old code was too clever(mostly too kludgy and not comprehensible) then do away with it. If the replacement causes any issues then use diff to find out what was changed.
I'm quite brutal when it comes to purging stuff like that. And I have been known to be rather sarcastic when I find stuff that isn't covered via unit tests. But that is an entirely different matter.
Maintaining code is hardly rocket surgery but normal housekeeping. There comes a time when the old pizza boxes have to go. Ideally before the roaches move in.
20 minutes into the future
Delete, early, delete often
Can't see Hindi?
And "re-implementation that preserves interface" is a term you call elegant?
20 minutes into the future
Deprecation hardly if ever works. Once you deprecate something then you will have to get in touch with all of the clients of that function and make sure you won't break anything. And then you delete it. Marking that bit of code as deprecated does exactly nothing and can be safely skipped.
If you are rewriting a function due to old cludgyness with asimple, elegant solution, then unit tests are your friend.
If you are changing the behaviour of a function due to a change request then you still need to notify the maintainers of the clients of that function. It may very well be that they need to change their unit tests. Otherwise when theirs fail due to your changes they will want to know WTF is going on.
Ah, the joys of distributed teams. Personaly I like the other guys well within punching distance.
20 minutes into the future
"Functionality is an asset, code is a liability." -- Damien Katz
If the code is not used you should not have the burden to maintain it. Delete it if you can. Even commented code needs to be maintained.
In the largest company I've worked for, the written rule was to explain and comment (using a specific syntax), never delete. The unwritten/save-our-sanity rule was to delete if the comments began affecting the readability of the code.
When working on code with hundreds of other developers, code that's commented out and explained/linked to a case id, can save a _lot_ of time. Say a piece of code solved an issue, but in turn created a performance issue. This did not become apparent until the code went live. The developer tasked with figuring it out isolates the affected flow and "... oh... someone added that credit check here a few weeks ago, I'll check that out first." That saves a lot of time compared to identifying dozens of involved files, then only diffing the specific methods involved in the particular flow.
1. Good rebuttal. No, seriously, proof by dogmatic assertion is great.
Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases, which is going to lead to unnecessary duplication (and probably hideous cut/paste code). It will expand the size of the codebase, because this is what happens when you add code, which will eventually cause problems on some platforms (trust me - I've been there).
2. Turn in your coding license. Now. Except for a very small subset of coders working on very specialised projects and using formal proofs of correctness, anyone who claims their code contains (or should contain) no bugs when first written is a fool, and a dangerous fool at that.
3. That may be your experience. Rolling back version control history to find out where defects were introduced can be very useful, and if the tools are good enough (which they are) it isn't exactly difficult either.
As for the idea that you can't track all dependencies from the deleted code to the whole system, if that's true to the extent that you claim then your design is screwed.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
If you feel that you need to leave deleted code in comments for a while or forever, then your version control system isn't working. Simple as that.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Comments.
Leave a comment saying something like: Version XX removed code to do YY because ZZ. The important things to comment are not what the code is doing (although that is useful) but the reasons for doing things and even more importantly the reasons for NOT doing things (eg: tried it but it was too slow).
Comments are an apparently obscure feature of every programming language. I say obscure as most of the code that I see uses it rarely except for a copyright block.
If rewrites are too complex you should split them up in phases. This is something few developers do, and something that can help you to test that the replacement code that you write does indeed what it's supposed to do. Between phases, testing is necessary - the more you can afford to test the new code, the less bugs you'll find later.
As a general rule, leaving commented code into commits that you make to the main repository is a bad practice. The general idea is that if you do things right, by the time you commit the code you should be pretty confident it does what it's supposed to do - and I might add that this is the main reason why I think rewrites are NOT for any developer. Attention to detail and thorough testing are a must.
When you commit commented code, you confuse other developers and add nothing of value to them. In most cases where I've seen devs do this, it's mainly because they are afraid they might need to roll back due to a lack of testing on their side.
And as a last note: version control is there to offer roll-back support, comments are not. It's about using the right tool for each job.
diegoT
don't mess with production code.
Keep deleting code from a program until it doesn't work. Then put the last bit back.
It is now as small as it can be, and it works. Voila!
I am anarch of all I survey.
Unwritten Rule #1;
.
.
Unwritten Rule #2:
.
.
The other rules offered here are good, but with all due respect, they've been written.
Gently reply
If you delete, and need to check it with version control you are adding time, effort and complexity of actions. And then instead of going back to do a cross reference you are going to introduce new bugs that can grow into weeds and cause this cycle of rewriting again.
Spoken as a fool who doesn't use Git. Seriously, get a grip man. Version control works. I use commits as my "save" feature, I branch a codebase 2 or three times per day. I keep merges (mostly) sequential. Here's how I switch back and forth between two different branches right in the same source directory, so that I can test old "deleted" code vs the new re-write:
$ checkout old-version-name
Now I can make an out of source build of the old version... Then make a new branch in the same source directory.
$ checkout -b new-version-name
Now I can make an out of source bulid of the new version... make some changes, and then save them.
$ git add . && git commit -m "Frobbed foo to make bar comply with baz"
Need to make a change in the old version, or look at some code? $ checkout old-version-name
It's better than SVN or Mercurial because you don't have to manage a bunch of folders of different branches, the files change automagically when you switch between your local branches. My IDE alerts me if the file's I'm about to edit were changed out from under it and need to be reloaded, so if the files need reloading then that's what I do. I use the diff viewer if I need to reference the old code while editing the new, or make another clone of my working repository with the old branch if I'll be doing that a lot. Seriously, you need to learn about distributed version control -- I don't need to worry about not committing something that's not perfect yet for everyone to see, I just commit it locally, and rebase all the ugly changes so only pretty gets seen in public -- all these commits and branches are on my local machine, so I can actually USE the version control rather than be its slave.
Oh what's that? You use CVS or SVN and so you don't have a choice? BULLSHIT. Init a Git repo within the SVN checkout. Set git to ignore .svn folders and SVN to ignore .git. Make a git branch for "master" be the SVN branch you submit to the centralized repository, then you can branch your heart out and clone like there's no tomorrow, and merge into master, then make an SVN commit when you've got shit sorted. Accept that you've been a moron about version control all your life, and actually learn to use it. The Truth Shall Set You Free!
I need a moderation option for 'good points, but excessive dickishness' Anyways, I do pretty much exactly the same as you do; although in the firmware world.
Right click, find usages. Then do safe delete.
You can switch branches in SVN just fine. It'll even merge local changes between branches for you without having to stash/pop.
1. Don't be a theorist -- profile your code! Only consider code for deletion that's not actually used in production ... But make sure your tests pass
2. If the code you want to delete code can't be profiled (e.g. its within a method), be creative... refactor it out into a method and profile.... Or write a log entries to disk.
3. Now delete the code - be bold!
4.
5. Get your change reviewed
6. Get your build UAT tested by 'the business'... perhaps by bundling with other minor changes
7. Along with a deployment plan, have a rollback plan (and a rollback build).
You notice I didn't say "use version control". Version control is good for managing the development process. Its not a shortcut to manage the entire software change process.
I don't alter production code, ever.
If I alter code it is going to go through a test release and be tested by other people first.
I've been programming for 14 years and I've learned no matter how trivial a change I make it is very possible to do damage unless the changes are completely tested.
So, I never alter production code, only code that is due to go through a testing cycle.
If rewrites are too complex you should split them up in phases.
Yep. In the VCS this you can easily do this using branches, doing all your development and testing outside of the trunk and then merging in a single commit back into the trunk.
The general idea is that if you do things right, by the time you commit the code you should be pretty confident it does what it's supposed to do
Not (necessarily) with branches. You can commit early and often since you're not changing the trunk. That means your commit log becomes a great timeline of the changes being made, you can almost always find older revisions of code to revert to and if anything goes wrong on your development platform you have a recent backup, which is always a good thing. If a commit is faulty then you can either correct or revert, but since no-one else is using your branch yet your faulty commit doesn't matter.
And as a last note: version control is there to offer roll-back support, comments are not. It's about using the right tool for each job.
Yep. In my view VCS is to provide rollback/backup/history. Comments are to explain actions being done to make code easier to read/follow, and in complex sections of code to explain the functionality to make them more intelligible (as an example to explain an algorithm being used, perhaps along with pseudocode for more complex ones). Comments should let you completely understand a program if you only have the single checkout, but don't need to give you any history.
version control.
In my experience, rewrites generally occur due to architectural changes or limitations, while refactors generally occur to improve code.
So version control is extremely helpful for refactors, but not really a solution in itself for rewrites.
If you delete, and need to check it with version control you are adding time, effort and complexity of actions. And then instead of going back to do a cross reference you are going to introduce new bugs that can grow into weeds and cause this cycle of rewriting again.
Spoken as a fool who doesn't use Git. Seriously, get a grip man. Version control works. I use commits as my "save" feature, I branch a codebase 2 or three times per day. I keep merges (mostly) sequential. Here's how I switch back and forth between two different branches right in the same source directory, so that I can test old "deleted" code vs the new re-write:
$ checkout old-version-name
Now I can make an out of source build of the old version... Then make a new branch in the same source directory.
$ checkout -b new-version-name
Now I can make an out of source bulid of the new version... make some changes, and then save them.
$ git add . && git commit -m "Frobbed foo to make bar comply with baz"
Need to make a change in the old version, or look at some code?
$ checkout old-version-name
It's better than SVN or Mercurial because you don't have to manage a bunch of folders of different branches, the files change automagically when you switch between your local branches. My IDE alerts me if the file's I'm about to edit were changed out from under it and need to be reloaded, so if the files need reloading then that's what I do. I use the diff viewer if I need to reference the old code while editing the new, or make another clone of my working repository with the old branch if I'll be doing that a lot. Seriously, you need to learn about distributed version control -- I don't need to worry about not committing something that's not perfect yet for everyone to see, I just commit it locally, and rebase all the ugly changes so only pretty gets seen in public -- all these commits and branches are on my local machine, so I can actually USE the version control rather than be its slave.
Oh what's that? You use CVS or SVN and so you don't have a choice? BULLSHIT. Init a Git repo within the SVN checkout. Set git to ignore .svn folders and SVN to ignore .git. Make a git branch for "master" be the SVN branch you submit to the centralized repository, then you can branch your heart out and clone like there's no tomorrow, and merge into master, then make an SVN commit when you've got shit sorted. Accept that you've been a moron about version control all your life, and actually learn to use it. The Truth Shall Set You Free!
Spoken as a COMPLETE fool independent of version control.
In other words, an out-of-control fool.
Out of all the code you're working on, HOW WOULD YOU KNOW THERE'S DELETED INFORMATION IN A PREVIOUS VERSION OF ONE OF THE MANY FILES?
You can't know that unless there's something there to tell you. And you're NEVER going to spend much time looking into a comment like /* deleted old processing and rewrote. 2009/11/4, A. Programmer */
Yeah, you're going to dig through old versions of the source just to see what happened?
No the fuck you're not.
1. If it works, don't touch it.
2. If it does not work, find out who did it and slap him (optional) and make him make it work.
3. If you cannot find the one who did it (or if he has been rightfully fired already), scrap and redo.
4. If code needs modification, do not modify the code but work around it.
5. Never EVER delete code. 9 out of 10 times you'll have to change it back anyway.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"Code that needs to be completely rewritten is crap code. We can argue how it came to be, but the reality is that every developer for one reason or another has created crap code. It is unavoidable."
I have found this to be the case for all code that comes out of TI for their MSP430 embedded processors. They use a convoluted system for their code that only a nutjob would love. I have thrown out their drivers for interfaces and rewrote them by hand just to avoid their crap. You DO NOT declare a function for your device driver in the .h file of another driver. WTF is wrong with their programmers?
Do not look at laser with remaining good eye.
My personal strategy is to first comment it out and put up a nice big comment saying why I removed it and when... then, at a later date, I'll actually remove it.(and comment appropriately about it in check-in)
The Digital Sorceress
I see no difference between Version control or commenting things out from a regression identification standpoint. The code isn't written correctly to do what you want.
Having commented code everywhere just clutters things up and my CDO (it's just like ocd, but in alphabetical order just the way it should be) kicks in.
So yeah, version control. There's a reason for it.
It's a description, and it's valid.
Calling it "refactoring" is just as justified as calling the act of adding odd numbers to even ones "oddification".
Contrary to the popular belief, there indeed is no God.
A colleague of mine comments everything and deletes nothing despite the fact that we use version control. This leaves the actual non-commented code difficult to read and understand. Also, there have been times I may need to uncomment the code to use it again, but it takes too long to readapt it to work with the surrounding code that has evolved since the commenting, let along to understand exactly what's going on to make sure there aren't bugs. For me, I think deleting commented code should be based on the following algorithm: x = the amount of time to understand and/or adapt commented code for reintroduction y = the amount of time to rewrite the same piece of code if (x > y) { Delete the code } else { Leave it }
I can't say I'm shocked to see all these comments advocating commenting deleted code. I wish you would make it easier on the hiring managers and put in your resume that is your preference so we can weed you out of the hiring process.
Years (now decades) ago I worked with a programmer who routinely replaced working/tested code with his own "streamlined" code that solved the specific problem in front of him. In other words, he deleted code that worked in the real world and replaced it with his code that solved for the test case. When asked what he was thinking, he said, "I didn't understand that code, so I replaced it with my own."
The short term result was chaos within the organization because the QA department "wasn't finding bugs" that were showing up in the field. The intermediate result was that he lost his job. The long term result was a whole bunch of hours taking out his changes and reverting code to its behavior before he was involved (not always easy after a few years).
If you don't understand code, don't delete it.
"Comments.
Leave a comment saying something like: Version XX removed code to do YY because ZZ."
Truly. You absolutly need to comment that... in the commit message.
An impressive number of interrelated questions for an Ask Slashdot! Let's start by dispensing with the red herring that a bewildering number of commenters have seized on: commenting out code versus deleting code. If you have source control, then from a point of view of history as well as a point of view of executable / deliverable, commenting out code is exactly the same as deleting code.
Right! Now for your questions:
The answers may be somewhat language-dependent ...
1. No, there is no language dependency.
What best practices do /.'s use when they modify production code?
2. (For beginners) Don't.
3. (For experts only!) Before it goes to production, test your code or (better) have someone else test your code.
Generally-accepted best-practice documents regarding code rewrites.
4. If it is a complete crock of shift, rewrite it.
5. If it is only mostly shit with some gems mixed in, refactor it instead.
Generally-accepted best-practice documents regarding code deletion / What are the unwritten rules of deleting code?
This is a special case of code modification, with a large number of possible reasons why it might be the right thing to do:
6. If it is not linked in, delete it.
7. If it is never called, delete it.
8. If it has conditions that are never met, delete it.
9. If it has no purpose, worth or value, delete it.
10. If it has too little purpose, worth or value compared to the cost of maintenance it imposes, delete it.
11. If it is performance code and it has no associated performance test, it has too little purpose: see point 10.
12. If you change your mind, put it back.
13. If your fellow programmer objects, then state your reasoning, but give them permission to put it back.
Generally-accepted best-practice documents regarding code modification.
14. See point 3 above.
15. If your tester objects, you screwed up mildly.
16. If your user objects, you screwed up badly.
17. Don't screw up badly.
You're right on this. When I wrote that part of the comment I was thinking about publishing (committing, merging, puslishing, etc) changes to a public / shared / main branch in the repository. The idea being: don't break a branch that was not specifically created for your change.
diegoT
Sometimes you need to leave a line like that in the code - else some programmer in 5 years time may attempt to put some more code in that does the same thing; being completely unaware of why that was taken out previously.
If it's posted in /., it is no longer unwritten.
Whatever you post / read here are NOT the answer of the original question.
If you are deleting functionality I highly suggesting leaving a permanent comment in saying what was deleted and when. Specs change all the time and the code may be needed in the future, a one line comment and hunt to SC will save from rewriting the functionality in the future. Without comments no one is going to search for it and it is lost forever.
They WERE written but then deleted. Search the git repositories for a few hours and you will find them out there somewhere.
To ensure perfect aim, shoot first and call whatever you hit the target
Declare all involved "Exempt" and work them like galley slaves!
Delete the code - it's the version control system's responsibility to maintain change history. The IDE should provide some non-intrusive visual indication of sections of code that have changed in the prior version. This provides the necessary alert and the developer can investigate version control for the details.
I don't know how many, if any, IDEs support this feature, but it seems like a good idea to me.
thats what git is for. ;)
branches are cheap - use them
As a general rule, leaving commented code into commits that you make to the main repository is a bad practice. The general idea is that if you do things right, by the time you commit the code you should be pretty confident it does what it's supposed to do - and I might add that this is the main reason why I think rewrites are NOT for any developer.
This is great in theory, but often it might be someone else looking through those lines of code again, and without the direct reference to what needed to be changed before, the new developer may reinsert the bad code for one reason or another.
Another case is when a feature is put in, but then the producer or whoever changes their mind before release. It's easier for the same developer to search through all the code for snippets they remember than it is to hunt through VCS, because you can't do a "find all files" on deleted code.
There are many, many other cases for comment over immediate deletion, and I do prune my own comments once I feel confident with the change. That said, it's a bit arrogant to assume that your modifications are going to be perfect, even if you do a decent job of testing it yourself.
I guess it's worth noting that where I work, there are usually only one or two people working on code at any given time, so commits are more focused toward backup than perfection. Your environment may vary.
Charisma is the measure of someone's ability to lie with a straight face.
sometimes if deleted bad code keeps showing up in the repository you need to be careful and keep the wooden stick an the hammer ready to kill it in a man-to-code combat on the local harddrive of some developer.
If you delete, and need to check it with version control you are adding time, effort and complexity of actions. And then instead of going back to do a cross reference you are going to introduce new bugs that can grow into weeds and cause this cycle of rewriting again.
The opposite of true for me. In my IDE( (Eclipse) is a single select from a drop-down menu for me to get a side-by-side comparison of new and previous, with new editable and old copyable. If I leave commented out old code, it is a scroll-up/scroll-down to compare new and old, which is much harder.
You need tools for the job. Version control is part of it, as has already been mentioned, and version control aware editors another part of it.
Consciousness is an illusion caused by an excess of self consciousness.
If you're immediatelly going to break it (step 3), why bother with marking it obsolete (step 1)?
In order to ensure that step 2 doesn't take an infinite amount of time (by ensuring that, while you're finding places where the function is called and removing them, someone else isn't concurrently adding new calls...).
Need to type accents and special characters in Windows? Use FrKeys
#1: Don't write the rules.
Sheesh, evil *and* a jerk. -- Jade
Oh my god, you can't delete code! It worked for us in 1998, and it's still working on our circa 1998 machines. What the hell are you thinking?!
Kidding aside, I comment and date old code, and add new code. It's not only there for restoration purposes (ya, ya, version control and stuff are there too), but if someone gets a new great idea on adding new code, they may find exactly that has already been removed with good reason.
When it's my own code that I maintain with no one else, I ditch the old commented code after about a year. Sometimes it sits there for longer, because it was actually good code that didn't suit that particular purpose.
I have one chunk of code in particular that won't get ditched for a longtime. It's a HTML filter, that takes all kinds of Microsoft specific characters and converts them into HTML friendly characters. I did it up better with a much smaller chunk of code, that can do a lot more, but occasionally I reference those old bits.
Serious? Seriousness is well above my pay grade.
As Wikipedia says, "Be bold." If you see code that needs to be deleted, delete it. Don't just leave it commented out and taking up space.
If you're removing functionality, then make sure you note this clearly in your commit summary, so that it can be found again if that functionality needs to be put back in.
Also, the article talks about rewriting code - throwing out the old and creating it again. This is generally a bad idea, even if you're starting with bad code, because all a rewrite does is exchange a known set of bugs for an unknown set of bugs.
You need tools for the job.
Trouble is, we have too many "tools" doing the job.
Either date- or version-based. "Delete after dd-mmm-yyyy" or "Commented out in 5.1". (Note how cleverly I avoid anticipating future version numbers. Management tends to change those things.)
To all the people saying "version control": I've seen enough botched configuration-management system changes and moronic branch management to know it ain't the be-all people think it is.
Spoken as a COMPLETE fool independent of version control.
In other words, an out-of-control fool.
Out of all the code you're working on, HOW WOULD YOU KNOW THERE'S DELETED INFORMATION IN A PREVIOUS VERSION OF ONE OF THE MANY FILES?
...
There are two scenarios that I can see here
In case B, I will know the code was deleted by comparing first version with the bug with the last version without the bug. This seems trivial.
In case A, the code was adding no functionality whatsoever to the program. I'm trying to work out why you would want to look up some code which was so useless that was in your program without adding anything? Wouldn't it be better to spend your time looking at random code samples on the internet, let alone using a Google search to see if there's a library related to your problem?
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
I use SVN and Mercurial, but I'm much similar in my heavy dependence on version control. That's what it's for. I often have branches that live for a couple of hours just to try things out. If I ever need to come back to it, it's all in the repository -- no need for me to keep code elsewhere, possibly to be lost -- the code isn't cheap, even if it's a "throwaway" experiment. I tend to do many small commits, each of a self contained single-purpose action done to the code -- exactly as if it were a save feature. I had one 24h session where I made ~60 commits. I also use version control for electronic/industrial automation designs, and there, with small documentation revisions, I sometimes commit every 10 minutes. I can't understand why anyone would think it's too much work. It takes a couple of seconds, and documents your progress as long as you are serious about commit messages (like you well should be!).
I don't particularly mind having separate working copies for things. Yeah, the git way may be more convenient, but these days checking out a 100 megs of stuff takes a few seconds anyway. Even on a virtual machine.
A successful API design takes a mixture of software design and pedagogy.
When removing code, consider commenting why it was removed. I've seen cases where code was removed then added back in causing bugs to reappear.
Before:
Log(“Shutting down”)
CloseLog();
Reboot();
After:
Log("Shutting down”)
Reboot();
Better:
// Don’t close the log file here because some other thread might still
// write to it during shutdown/reboot, which could cause an error dialog
// that prevents shutdown. The file will be closed anyway by the OS.
Log(“Shutting down”)
Reboot();
That's completely asinine! Leave commented code because the code you write to replace it will be shit. Well maybe the code you write to replace it will be shit but not the code that I write to replace it. Besides we're not talking about the code that remains - we're talking about code that's been deleted. Often that code is shit and should go - period.
In my first programming job, several of my more thankless tasks were fixing up code where the source had been (for one reason or another) lost. Back in the 1970s, this was not uncommon. The upside of this was that patching binaries directly was (and, of course still is) a challenge, and a nice change from the tedium of COBOL.
Of course, in those days patches were usually submitted via cards punched on 029 door-stops, and version control was handled with a device generally known as a pencil. This lead to an approach where the fastest means to obtain a usable code was the best, and documentation didn't really come into it unless the programmer was not up to scratch.
I don't quite get how this qualifies as news. This story points toward arstechnica which basically just summarizes(wrongly) the question and answers from programmers.stackexchange... The actual question name was "Unwritten rules of rewriting another team member's code" and covered rewrites, not just plain deletion.
Whoops accidentally posted as AC. mehhh
Yes, one can and should dig through old versions of the source. Your employer paid for it, you might as well use it. Like, um, duh!
Similarly, there are those great things called GUI interfaces to version control. Heck, some even have with fancy graphs that show what files were modified and how -- including, incredibly enough, the aggregate counts of inserted, modified and removed source lines. Who'd have thought of that! Never mind the branch/merge graphs, etc.
And, of course, viewing the diffs of larger commits is just so damn hard, right?
The parent post is some bumbling idiocy, it seems.
A successful API design takes a mixture of software design and pedagogy.
What kind of a nutjob is not at least familiar-in-the-passing with the project's history? I mean, fuck, suppose I'm an employer, I paid people to use version control, not NOT to use it. Using it doesn't mean merely committing things. First people are all "learn your history hurr durr", then they go to work and promptly forget it. What's wrong with people? Sigh :(
A successful API design takes a mixture of software design and pedagogy.
But that provides -- literally -- no value.
You lose exactly the same functionality as you do when commenting it out, and you lose no information at all if you are using version control, so neither of these concerns is a valid reason to prefer commenting-out over deleting.
Unit tests aren't relevant here. The relevance is that deleting code from source files doesn't delete it from version control history, so if for some reason you need to recover the code, its still there.
Not necessarily. "There is a better way to do it" doesn't mean the code is crap code, but sometimes the better way requires a complete rewrite. And, of course, deleting code doesn't mean rewriting code. Sometimes, requirements have changed such that previously-required functionality is no longer required, and you aren't "rewriting" the code that provides that functionality, you are simply removing it.
Again, no. Even code that needs rewritten because it is of exceptionally poor quality can be of poor quality for reasons other than mixing concerns.
That may be true of some crap code, but even where the code is hard to get a grip on because of its complexity, it doesn't mean the requirements are (even if they were for the author of the crap code, which may just have been because the requirements were unclearly or incorrectly specified at the time the original code was written, and they may be clearly specified now.)
Possibly.
Having a handle on the old code isn't relevant to introducing bugs. Having a handle on the current requirements is, and old code that is "crap code" that "does quite a bit ... incorrectly" is not likely to be the best resource in understanding those requirements.
The crap code that does things wrong isn't going to tell you if things are bugs or the correct answer, the requirements will tell you that. The crap code is, at most, going to tell you if the bugs were there before (of course, you can do the same thing by attempting to reproduce the bugs on the old build, and, in fact, if the problem is, as you suggest, that the old code is hard to understand -- and even if it is not -- the best way to tell if the bug is introduced with the code change or consistent with the prior behavior is to test with the old build, since that's a direct confirmation of the behavior, rather than what it appears from the code that the behavior would be.)
When you switch version control software...you often lose your history and ability to see what was done before. Doesn't mean leave a million lines commented, but some here and there is reasonable.
People in cars cause accidents....accidents in cars cause people
If the final code has something that is likely to look like a code smell to someone unfamiliar with why it is that way but which has a good reason -- whether as a result of deleting code or not -- it may be valuable to put a comment explaining the reasoning so that someone coming to the code has the value of whatever process got to the end result.
But that's not so much a comment about deleting the code (or adding, or whatever change made it the way it is -- and heck, it could be even the first version of the code, because the original programmer might have realized the right way), which is the process of how it got to be the way it is, as it is a comment about the current logic of the implementation.
You can switch branches in SVN just fine.
And as a bonus you'll have time to go get a cup of coffee!
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
So, when you realize a year and several thousand commits later that the rewrite neglected to handle a rare and complicated corner case, what's the easy way to find the previous version in the commit tree?
That's a serious question by the way. I'm still fairly new to VCSs, but the one big lack I see (and it may just be to EasyMercurial's stripped-down gentle-intro interface) is there's no simple way to say "show me the history of this specific section of code". Now sure, in an ideal world the commit comments would let you immediately recognize the relevant commit when you saw it, but thats still be a lot of manual searching to do. If I remember correctly hg does have the ability to trace the history of a particular file, but there are plenty of situations where a file may have seen lots of changes for lots of different reasons. Is there any mechanism available to quickly pick out just the changes to, say, a particular function? Or really, even just list the relevant commits.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Bugs are relative. I don't write bugs; others only claim a write bugs. Since the client is among those making the claim, then I change the code to remove what they call a bug.
And "others only claim a write bugs" is not a bug. It only doesn't conform to your people's version of the "English language". But I will correct it to help others that don't read my language: "others only claim I write bugs"
How is this not an "Ask Slashdot" article?
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
That's all I ask in regards to comments -- no /* . . . */ to comment out multiple lines of code. Nothing I hate worse than spotting something in code that piques my interest only to discover there's an open /* several lines above it (often times scrolled out of my window). So I make a point of ensuring that every comment is identified on each line (a complete /* . . . */ set, //, or whatever the particular language dictates). Only exception being multi-line text or narrative -- I have no problem with that being wrapped in /* . . . */.
Yeah, yeah, I should use a better IDE that would identify all those lines as comments, but many times I'll be browsing code with nothing more than vi or grep.
No I feel you should comment it out for one version, or one iteration.
This is exactly what I do. Sometimes I leave it for a couple of versions, but basically you want it to still be there long enough to be sure that deleting it was the right thing, then get rid of it to clean up your code. Leave a good comment in the version history and you're done.
I agree with SerpentMage that "bad code" may in fact be accomplishing something, and that unfortunately the badness may make it difficult to understand. I also agree that if the code was put in place to handle some unusual circumstance, it probably wasn't causing unit tests to fail. (A good programmer would probably add the edge case to the unit tests.) Before deleting (or commenting out) code it is important to try and understand it, and to incorporate that understanding into your comments. For example ...
which will never be triggered since maxSubcasses will always be 0, though maxSubcases won't.
True story: many years ago I found an obscure FORTRAN bug in which an undeclared variable had a small positive value and worked successfully as an epsilon until a change in OS caused it to have the value 0, resulting in code failure.
## Deleted code that computed the maximum possible number of subcases as maxSubcases because ## no subsequent code references maxSubcases
If you don't understand what the code is doing, you may want to ask someone with an historical understanding of the code. For example perhaps there used to be a memory problem that required a workaround, and you are dealing with code that is currently not needed.
On the other hand, maybe a fix was put in to deal with a situation that could arise again, but because the situation was rare and the fix was buggy (no surprise since it was written by the author of the maxSubcases code) the code was removed, and updates were left for a day that never came.
Running some kind of code checking software might also be useful, especially if you are using a language that doesn't require you to define variables in advance, but conveniently instantiates them for you.
There could be code that says if (maxSubcasses > 15000) {
What is it about git that spawns such unutterably foppish arrogance? It's like a hipster learning about hipsterism for the first time. *shudder*
I say this as a daily user of git in professional and non-professional work. I love it and recommend it, but ... seriously?
thats what git is for. ;)
branches are cheap - use them
Merging branches, on the other hand, can be a royal pain.
Well that took a while. Seriously, aren't there coders here who can cut through bullshit? Code modification, which includes deleting swaths of useless code and putting in something simpler, is called "refactoring". And there's been a shit-ton written about it.
The refactor vs rewrite debate is likewise ancient. See: Mozilla.
These are not unwritten rules. They're just things the author is ignorant of.
If you have version control, and yet still fear deleting code, then methinks your regression suite and code review process are weak.
Do you have a good handle on the coverage provided by your test suite? Is the code change, including the deletion, talked about during code review before your dev branch is merged into mainline? Does your defect tracking system allow you to tag defects with an 'incorrect deletion' marker? Are you adding a targeted test to the regression suite for every diagnosed defect?
If 'yes' to all, then delete it and let version control keep the history for you.
1. It's easier to write the second time.
Yes, one can and should dig through old versions of the source. Your employer paid for it, you might as well use it. Like, um, duh!
My employer told me in no uncertain terms to "just Git 'R Dun!" He doesn't want me spending a lot of time looking at how things USED to work.
If a chunk of dead code is still present and commented out, I can scan it and go on. Very few of those fancy tools can give me feedback that fast.
Use a version control system that ties changes to a problem ticket. All versions and version comments for a paticular problem should show in the ticket. Nothing gets checked in unless tied to a approved ticket. Example systems: Clearcase with Clearquest, Subversion with TRAC.
If your changing code because the old code had a bug then you need to add test cases to your test scripts. Add tests that reproduce the bug and fail in the old code. Add good comments to the test documenting what defect the test reproduce. Then if someone goes back and reverts the change in the source the test will fail.
You don't talk about deleting code!
not that they are unwritten. There were detailed instructions on this topic.
The problem is that the instructions were deleted before being implemented.
A koan for a new age.
Damn dude, not meaning to troll here, but sounds like you've written quite a bit of buggy code and thus benefit from your own approach of cross-referencing "bad" working code with yours... which I believe is legit, but when replacing large(er) chunks of code like that I find a notepad approach best, write down what the code is doing, and from what you can gather what the code's supposed to be doing (original rfp is priceless here, senior users are too) including the problem you're trying to solve by rewriting it (businesses benefit more from functional code than good code is the sad, but hard truth). So I wind up with a mini-rfp functionality requirements doc after which I delete the code in it's entirety (after source-control commit, making note of the commit # depending on size of team), and rewrite it again off my requirements doc, test it to make sure it meets requirements & send off for testing.
It might seem similar, but the problem with merging good code with bad code on anything more than a quick patch is ime bad code tends to be very un-flexible so making a 5 minutes change takes 30 & because you've altered the structure of something held up on air, you've introduced possible bugs again that now you can't account for because it's not your code that's causing them, but your code is integrated into the bad code if that makes sense. So a moderate change can turn into 30 minutes into 4 hours of tracking down an anomaly.
Depending on what is being deleted, I flip-flop back and forth between commenting out chunks for a revision or two and then deleting, and just deleting. For small sections, I tend to just straight delete. In rare circumstances I'll delete but replace the code with a comment like "Used to do X here, but now it's covered by Y" but only until Y becomes the standard and then those tend to drop off.
For larger sections or whole functions I tend to comment out first until I'm sure the new code is working then deleting it. There are a few reasons behind this:
1) There is an advantage to having the old code instantly available (no diffs, no downloading to a separate directory, etc) to make sure that all the functionality that was previous there is still in the new code. It's very nice to go back and look when the new code isn't working right to flow through the old code and see what's missing. "Oh, we used to set this flag, but when I optimized I did away with it. Apparently, someone is using it much later in the code. Guess I need to put it back." *
2) There is a standard of, when creating new database functions (a new table), that there be a set of default functions; Create the table, Load Defaults (if applicable), Insert a record, Update a record, Load a record, and Delete a record. But as time goes by developers may create more specialized versions of these functions (JOINing other key tables, for example). More updates and soon no one is using the regular functions as the specialized ones work for what they need and then some. So if I see a function not being used any more I comment it out saying, "Deprecated; try using FunctionName() instead." If nothing breaks immediately, and no one complains for a few revisions, the extra functions go away.
* The better, but not real-world, solution would be contact whoever maintains the code that used the flag and see if we can they can update/optimize the code to work without the flag.
so are local repositories, it's beyond me why anybody would commit non-working code to a non-local branch without getting it to work first, waste of a commit # if there ever was one. One cool thing I've seen people do is set these up with GIT & Tortoise on the side from say like TFS, or other non-locals, and commit the shit out of those for easy roll back (once you've done it a few times it's real easy) and only make relevant commits to the rest of the team.
Spoken as a COMPLETE fool independent of version control.
In other words, an out-of-control fool.
Out of all the code you're working on, HOW WOULD YOU KNOW THERE'S DELETED INFORMATION IN A PREVIOUS VERSION OF ONE OF THE MANY FILES?
You can't know that unless there's something there to tell you. And you're NEVER going to spend much time looking into a comment like /* deleted old processing and rewrote. 2009/11/4, A. Programmer */
Yeah, you're going to dig through old versions of the source just to see what happened?
No the fuck you're not.
Wait, what?
If you are skipping step 2 you are causing a lot of extra work for yourself. If the bug was caused by Joe's last check-in, not only should Joe fix it because it's his fault, Joe's already familiar with that section of code and can probably fix it orders-of-magnitude times faster than you can. If not, Joe can help you fix it. If you caused the issue, you now have a diff of what was there before and what's there now. Step 2 is integral to team development when you can never be sure when/how files are changed. Maybe that's the difference? Commenters don't work on teams, so they only learn to use change control as backup?
If you have a good source code management system, you should get this ability for free.
If you don't and it's not a throwaway project, get one.
If it is a throwaway project, then there probably aren't any rules.
Once you know you can un-undelete it, the same rules apply as to adding or changing code:
* Make sure your edit improves the code.
* Don't introduce any bugs.
* If you can't avoid the previous rule, don't introduce any important or subtle bugs. Especially don't introduce any important, subtle bugs.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
But the rest of the time you have a bunch of useless comments sitting around that are not relevant, slowing down your real work so it is harder to get the job done.
Removing needed old functionality once tested should be the exception not the rule. Coding for the exception is just silly, true going through version control is a bit more time consuming (not majorly so) but in some ways it is also better since you have runnable code, with the same structure and you can see exactly what is happening.
"just Git 'R Dun!" which I think means just get it done, is a good way to dig yourself a nice big hole, you have to get it done right, surprisingly this turns out to be the fastest solution in most cases anyway since you don't have deal with the edge cases that so called quick solution created.
The only time you should comment out a deletion is if the code is it is being temporarily removed.
But you need to test it again anyway, since the unchanged code's input may have changed or the output may need changing.
Just because you haven't changed a particular piece of code, doesn't mean you shouldn't test it again.
So now you have to go back "some time" in the future to clean up the mess you left the first time? Who's going to pay for the cleanup?
Commits should be small and should only encompass a single bug or feature, which is logged in you bug tracking system. The commit should also be tagged with the bug id.
Try and submit a patch with a bunch of commented out code to a major open source project and see if it gets accepted.
immutable source code? The problem with this is that someone will inevitably add new calls to the old function (with it's broken behavior), even if it's marked as deprecated.
Srsly guise, if you're asking this question, you're in the wrong field.
The point why removing code is so hard is not, that its hard to restore. We have VCS for this.
But its hard to discover, the code ever existed. Who goes to the VCS and searches for old commits, when implementing a new function? If you weren't there when the code were in use, its unlikely you find it in the VCS instead of rewriting it.
So removing code is a decision about making it hard to find, that it ever existed.
One solution would be to remove and leave a comment behind "here was code, which was removed in a commit at $DATE". What other solutions are there, for this dilemma?
The whole point is: it does not take a lot of time -- that's what the tools are for. If you're not supposed to look at old code, then, well, it should be deleted and you shouldn't look at it :)
A successful API design takes a mixture of software design and pedagogy.
I would favor keeping the old repo around read only
The bean counters sadly wouldn't favor such unnecessary expense. And legal won't let you do it...
;-)
I understand your point but reality doesn't always nicely fit what would work best. That said, hopefully it is an odd case and you aren't switching source control vendors too often
People in cars cause accidents....accidents in cars cause people
So now you have to go back "some time" in the future to clean up the mess you left the first time? Who's going to pay for the cleanup?
By "some time" I'm meaning days or weeks, not many months or more.
Slap everything commented that doesn't need to persist with a "CLEANUP" tag and scan for them pre-release or at then end of a run of sprints (and/or as you approach a release, where-ever it fits in your flow) as part of your other housekeeping tasks. Give the job to a junior so he/she might learn from the changes (have a more experienced dev to hand in case of questions, and to try make sure the wrong things are not learnt from less "clean" work).
Try and submit a patch with a bunch of commented out code to a major open source project and see if it gets accepted.
Each open source project will their own preferences and rules which are fine by me, but equally are not my problem currently (if I were to have something to contribute I'd would of course try to fit into the project's preferred coding standards (or just release my changes as-is and if anyone else wants to clean them up and claim the credit they can go right ahead, if not then fair enough too)).
"just Git 'R Dun!" which I think means just get it done, is a good way to dig yourself a nice big hole, you have to get it done right, surprisingly this turns out to be the fastest solution in most cases anyway since you don't have deal with the edge cases that so called quick solution created.
Unfortunately, my reputation IS for doing things correctly and carefully. I was very specifically told that that was my problem and that I should be more like "Joe" who got stuff "done" faster because he didn't think things through or put in exception-handling logic. That it was, in fact "better" to reboot the server daily than to "waste time" making an app that cleaned up after itself. They were very big on "Done" in that particular shop.
I used to always delete dead code immediately. I've backed off on that lately because occasionally it turns out that the cure was worse than the disease and it's good to have the previous-generation code available for immediate reference. Especially when I have the offending module in dead-tree form far from a differencing server. And I'm afraid that in any event, the version-compare tools available to me have a very definite latency - I can't just hover a mouse and have the changes immediately pop up in milliseconds. Instead I have to explicitly issue a set of secondary commands, wait for the differences to be generated and the UI components to initialize and scroll as needed. Not a LONG delay mind you, but long enough to discourage casual usage.
Why would I want that? Where I work, that would amount to an unnecessary layer of bureaucracy. (and would be hell because our codebase is multinational) Plus, I do a lot of original development, an only a moderate amount of maintenance and fixes.
Charisma is the measure of someone's ability to lie with a straight face.
not necessary if you're branching 2 or 3 times a day and you're connected to your repro by something faster than carrier pidgeons.
And if your code base is small.
OTOH, if you have several million lines of code and you switch branches a dozen (or two dozen!) times per day... SVN is really painful.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
the cost of switching is relative to the size of the diff, not the size of the repository. if you're branching 2/3 times a day, then the diffs are small, and therefore, quick.
"Sometimes you need to leave a line like that in the code"
Wrong: you never will need to do that. The comment "Version XX removed code to do YY because ZZ" explains the history of that code and, as such, it belongs to the history-tracking tool. If you feel an explanation about why some code is in a particular way instead of another, go ahead and add a comment, but that's a completly different issue.
Not neccessarily - the codebase can drastically change between releases, and if you are attempting to backport fixes to multiple releases it can be really painful. Not to mention you need a great connection to your SVN server (which for a large team also needs to be fairly beefy). Git makes this much more efficient, and it is far easier/faster to identify where regressions occurred, determine the ancestry of lines within files, etc.
But anyway, SVN is relatively good. We should be bashing CVS and Clearcase!
gitk the file?
if you want to argue GIT vs SVN I'd stick to SVN's inability to properly track change ancestry through branch merges. that's the reason I quit SVN, not the performance. a beefy server and a GigE switch are next to free.
They aren't free in most businesses though. It's better to make staff suffer on 100 (or even 10) mbit networks and Pentium 4 machines with 2GB RAM than to spend any money on hardware that may not make them any more productive. At least thats the mentality of the IT departments I've seen!
Oh that's fine for me. I just hope at least some of those incompetent it departments are in campanies that I compete against. Every little bit helps.
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.
===
I do the following. I take a copy of the code before doing the delete, along with a timestamp. I add a brief paragraph comment in the code to indicate where to find the code before the image. I add to my paragraph, when to delete the paragraph itself.
When the 6 months, or 18 months lapses. I delete the paragraph and the code I set aside as a separate file months before.
I do not like long descendency paths for subversion or git. If the new code is clean for 18 months, I do a sv removeal and then register it again.
Leslie Satenstein Montreal Quebec Canada
Having JUST gone through this the only rule about deleting code is to NOT delete code someone is actively working on just because you don't understand or like it. I had about 3 weeks of work blown away by a "senior" developer who didn't understand or like what I was doing, deemed it unnecessary, and nuked it in a single check-in even though I am actively working on it without even consulting me.
Rule #1: Ask yourself, "Am I being an asshole if I remove this code?" If the answer is yes then don't do it.
I haven't thought of anything clever to put here, but then again most of you haven't either.
I was very specifically told that that was my problem and that I should be more like "Joe" who got stuff "done" faster because he didn't think things through or put in exception-handling logic. That it was, in fact "better" to reboot the server daily than to "waste time" making an app that cleaned up after itself. They were very big on "Done" in that particular shop.
I'm guessing that particular company sold the code to other companies and didn't actually use it themselves? That's the only (immoral) way I can see justifying such an attitude.
I was very specifically told that that was my problem and that I should be more like "Joe" who got stuff "done" faster because he didn't think things through or put in exception-handling logic. That it was, in fact "better" to reboot the server daily than to "waste time" making an app that cleaned up after itself. They were very big on "Done" in that particular shop.
I'm guessing that particular company sold the code to other companies and didn't actually use it themselves? That's the only (immoral) way I can see justifying such an attitude.
Unfortunately, no. They are a bank. A rather large one.
Ah, a bank. No need to explain further.