What Are the Unwritten Rules of Deleting Code? 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?"
The more..... (Score:5, Insightful)
Re:The more..... (Score:5, Informative)
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..... (Score:5, Insightful)
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..... (Score:5, Insightful)
Why not just delete it right away? Commenting out code in version control just creates more changes.
Re:The more..... (Score:5, Insightful)
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: (Score:3, Insightful)
I always keep in mind that the code I'm working on will be assembled, and the assembly is smaller and tighter with assembly oriented coding. So I do comment out working code and replace it with an alternate if I think it could be more efficient.
Re:The more..... (Score:4, Informative)
He didn't say that. Alternate coding will give you a different assembly - eg capturing a keypress in a loop is different if you use a (basic) while-wend or a for-next. Comments are ignored in assembly anyway.
Re: (Score:3)
deleting comments is hardly an onerous task.
But if your team has such little concern for teamwork and code tidying as they go, then your problems run a little deeper than leaving comments present.
Re:The more..... (Score:5, Insightful)
> remove after it has shown to work
Seriously? Do you mean you don't have unit tests and quickie smoke screen tests for developers to run before they check in to prove their new code works and hasn't broken anything?
Tell me where you work, I don't ever want to buy one of your products.
There's unit tests, and then of course the ultimate test: the production environment. If you set up perfect unit tests every single time, then you won't notice the difference between the two. If you're human like the rest of us, then every so often an assumption you hadn't even realized you'd been making will slip through your unit tests and you've got a production bug. But hey congrats if you've never promoted a bug to production before.
Re: (Score:3)
Someplace that will only grudgingly give you enough time to write sloppy quick-and-dirty code. Try telling an accounting troll that you need another third as much time to make sure your code is covered. I believe that's commonly referred to as a "Career Limiting Event' as you soon get a reputation for padding your time estimates with activities that do not directly create value. ("Value" being defined as "something we can sell", not "good code". Most of the time those aren't the sa
Re:The more..... (Score:5, Interesting)
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..... (Score:5, Insightful)
If this is your goal, then you should just practice code-review of every commit and that'll achieve the same goal.
Only if every single developer that might look at the code reviews every single line. That doesn't scale beyond a small team.
In general it's best to delete unwanted code, but in some cases (e.g. where the code being changed is related to working a bug in a third-party's software, so it may not be possible to tell what the "right" code is apart from by experimentation) it can be useful to leave the deleted code around for a while to notify anyone fixing bugs in that area - provided a suitable comment explains why the code has been commented out. Leaving the code surrounded by "/*...*/", but with no explanation, is not helpful...
Re: (Score:3)
The only case I see for leaving it in is if the code you took out is the obvious solution, but forever reason won't work in this case. Then it's a good thing to leave it in along with a comment stating why you use different code. That way, there's less risk that a future programmer refactoring code will replace it with the obvious solution.
Anyhow, this whole article seems to have been copied from ars.technica. Don't sink this low, /. submitters - you are better than mere copyists.
Or is this the direction
That's what I do too, (Score:3)
Re:That's what I do too, (Score:5, Funny)
Unfortunately bitter experience prevents me from being too nasty on this one, because too many times I've been through the process of having good test policies in place, followed by senior management decreeing that in order to meet deadlines, testing and documentation will have to fall by the wayside 'just for a few weeks'. I know it would count as justifiable homicide, but I still can't afford the court time. ;)
Re:That's what I do too, (Score:5, Insightful)
If the timeframe is borked, then I need to know so I can talk to the client about cutting features, postponing release, release in stages, etc. There is a lot you can do. But shoving out stuff that doesn't work or is unrelyable is something that will never be properly resolved.
If you desperately try to meet the release date and you actually somewhat succeed, then the books are closed on that release. But if you spend a lot of time after the release on bug fixing then eyebrows will be raised and your competence as a developer will be questioned. It's not your job to make management happy. It's management's job to make your job possible.
On unrelated news: Overtime is a clear indicator of management failure. Also massive overtime to meet deadlines never work and is never worth the effort. Been doing this for 15 years and I yet have to encounter one instance where this actually proved to do more good than harm.
Re: (Score:3)
What kind of version control do they use so that getting rid of it saves time? Do they tar it to half inch tape upon "commit" and write the commit message in a paper logbook? The fuck?
Re:The more..... (Score:5, Insightful)
If you're going to do this, YOU HAD BETTER COMMENT ON WHY YOU COMMENTED IT OUT. Too often I come across a block of code that is just commented out. A quick glance means it had a purpose, but for what reason, I'm not sure because apparently it isn't needed anymore. So then I ask "why?" But there is no answer to this question. This is possibly the worst feeling of working with code--the idea that something was there, now is not, but they left it in for some reason and you don't know why.
Now you're left with a couple scenarios:
It is like walking into an offline factory line. Most bystanders will simply think "I had better not touch this or it could cause serious problems" so the only people in full control was the last shift of factory workers for that line. Meanwhile similar lines are still operating so you're not exactly sure why this particular production line was halted.
Meanwhile if the code was in version control, I get a much clearer picture from diff on what exactly changed. If you just comment out a giant block and leave it there, check it in, then diff shows me that 2 lines had a comment added (in the case of block comments) or all the lines are commented out (modified, for single line comments). Now I have to diff again and skip to the version before that to get the picture I want, but now I may see other changes that may not be relevant.
Either way, if you are commenting out code for the first two scenarios I listed, you need to think again about your version control system and manage it better. Experimental or untested stuff should be branched, not visible to other devs otherwise people make mistake it for production code. If I see commented out code blocks, I'm simply going to delete them myself because I can't read your mind and never will be able to.
Re:The more..... (Score:5, Insightful)
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.
That's a fine sentiment for a one-man dev team with a relatively small codebase, where you know what you're doing and can keep a handle on things, but for larger teams, people who leave commented-out code in place are annoying for everyone else.
As you said already, it's in source control anyway, so why bother leaving it there even for one version?
The counter arguments are that it causes additional diffs and commits that are unnecessary, and it gets in the way for other developers -- it harms readability.
And very often, despite best intentions, it ends up being left there for a lot longer than was needed. The original developer may not come back to that file for some time, and after just a few revisions, no-one is quite sure which bits of commented out code should be deleted and which should be left in place. Or maybe even maintained -- after all, if it's been left in place, that implies it might have to be re-instated, so if the code around it changes, the commented out code really ought to also be tweaked to keep it in line.
No-one has time to stop and figure it out either; the temptation is always just to leave it well alone -- if it's been left there, then there must have been a reason, but it's not my problem, so I won't touch it. End result, a year or two down the line, and we have huge quantities of dead code floating around, which probably wouldn't work anyway even if it was re-instated, and someone has to waste time with an excersise to go through the codebase and remove it all.
In your world of your own little projects, keeping dead code floating around may sound like a good idea, but in the real world it really isn't.
Re: (Score:3)
Re: (Score:2)
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 a great idea (Score:5, Funny)
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: (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
Not the first example - Ken Thompson predates that with his "One of my most productive days was throwing away 1000 lines of code."
Re:The more..... (Score:5, Insightful)
"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 (Score:3)
Re:Your VCS should manage this (Score:5, Insightful)
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: (Score:2)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:3)
Also some code's functionality is sufficiently complex that it is unclear what the functionality is. (eg depends on the external world in a complex manner).
Some code works correctly despite/because of compiler/processor bugs, and changing the code in a manner that should not affect its behaviour, actually does, for undocumented, and possibly previously unknown, reasons.
PS not everyone writes code for Windows.
Revertable (Score:2)
what best practices do /.'s use when they modify production code?"
Should be able to easily revertable
Re:Revertable (Score:5, Interesting)
Re: (Score:3)
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 (Score:5, Informative)
Re:Version Control Is Your Friend (Score:4, Insightful)
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 (Score:4, Insightful)
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: (Score:3, Insightful)
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.
W
Re:Version Control Is Your Friend (Score:4, Informative)
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.
Source control (Score:5, Informative)
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 (Score:4, Funny)
Let Vigil delete your code for you when it's wrong and must be punished.
Re:Vigil (Score:5, Informative)
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: (Score:2)
Vigil deletes code that does not pass assertions (or "swear", as they call it).
What mechanism prevents those assertions from being wrong?
Re: (Score:3)
Drinking sufficeint alcohol before pressing [Enter] is the standard mechanism. (It has been known to fail, but the results are not normally painful at the time).
You may need to indicate that something is removed (Score:5, Insightful)
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 (Score:2)
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'
Re: (Score:2)
Re: (Score:3)
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 (Score:2, Informative)
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?
There are only 2 important rules (Score:2)
#1 Make sure your code is better. ... Don't get caught!
#2 If it isn't
Re: (Score:2)
#1 Make sure your code is better. ... Don't get caught!
#2 If it isn't
You forgot...
#3 ???
#4 Profit!
Agile/LEAN applies here (Score:3, Insightful)
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'.
My rules for deleting code (Score:5, Funny)
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.
Tests green, checked into git? (Score:2)
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 alwa
Our Rules (Score:2)
There used to be rules ... (Score:5, Funny)
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.
Don't break the API (Score:2)
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.
I don't understand the question... (Score:2)
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.
This comment has been deleted ... (Score:5, Funny)
If there was *any* kind of consensus... (Score:2)
Mentioning the deleted code (Score:5, Insightful)
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).
Seriously (Score:2)
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-chang
Simple: Don't (Score:2)
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 prac
Re: (Score:2)
Pay it forward with good practice, don't comment out code. Comments are for comments, not code.
Use Version Control!!! (Score:2)
Uhm delete it? (Score:2)
Delete it. Plain and simple.
Put a comment/bug id in the commit log.
What's the problem?
version control and start/end with working code. (Score:2)
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.
Explain why it was removed (Score:4, Insightful)
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();
Re:How can ... (Score:5, Informative)
version control.
Re:How can ... (Score:5, Insightful)
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.
Re:How can ... (Score:5, Insightful)
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.
Re:How can ... (Score:5, Insightful)
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.
Re:How can ... (Score:4, Insightful)
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.
Re: (Score:3)
thats what git is for. ;)
branches are cheap - use them
Merging branches, on the other hand, can be a royal pain.
Re: (Score:3)
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 f
Re: (Score:3)
Re:How can ... (Score:5, Informative)
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!
Re:How can ... (Score:5, Insightful)
Re: (Score:3)
You can switch branches in SVN just fine. It'll even merge local changes between branches for you without having to stash/pop.
Re:How can ... (Score:5, Funny)
You can switch branches in SVN just fine.
And as a bonus you'll have time to go get a cup of coffee!
Re: (Score:3, Insightful)
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 hap
Re: (Score:3)
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 com
Re: (Score:3)
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 featur
Re:How can ... (Score:5, Insightful)
"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?
Re: (Score:3)
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.
code block history (Score:3)
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 comment
Re: (Score:3, Interesting)
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.
Re: (Score:3)
"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.
Re:How can ... (Score:4, Insightful)
Re:How can ... (Score:5, Insightful)
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.
Re: (Score:3)
The refactor vs rewrite debate is likewise ancient. See: Mozilla [wikipedia.org].
These are not unwritten rules. They're just things the author is ignorant of.
The first rule - If only that were true. (Score:2)
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)!
Re: (Score:2)
So your answer is to never change code once its written and just hack on the sides if behaviour needs changing?
Re: (Score:2)
It's more like breaking already tested code is wasting too much time...
Re:The rules (Score:4, Interesting)
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.
Re:The rules (Score:4, Insightful)
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.