

Delete your code - antonpirker
http://www.anton-pirker.at/delete-your-code/

======
morgante
Strongly disagree with simultaneously deleting branches _and_ commented out
code.

We can (and should) safely delete commented code _because_ we have branches
which track the evolution of features and random experiments that might
someday be useful. So long as the branches exist, we can always recover that
code we just deleted.

But there's not value in deleting old branches. They represent the history of
a project's development and should be respected as such.

~~~
tinco
If an experiment that was branched out but abandoned and forgotten, but still
possibly useful, then I think it's better if it gets an entry in the
documentation.

The source repository is a workplace, not a museum.

Just create a `bla-rearchitecting-experiment.md` in your `doc/` and paste the
relevant code and a paragraph or two about what it does, why it could have
been better and why it was abandoned. Now your history is in the place it
should be, and not cluttering up the workspace of your successors.

~~~
morgante
That's very impractical for large-scale rewrites, which can easily touch
dozens of files but still be abandoned (at least temporarily).

History belongs, well, in history.

------
danieltillett
There is some value to leaving in commented out code when you change code from
something that is simple to understand to something written for efficiency. In
one of my projects I have a few functions that account for most of the
runtime. The original functions were easy to understand, but slow. I rewrote
them using a whole series of complicated code that even I forget what it is
supposed to do. It really helps me to look at the original functions to know
what the hell I was tying to achieve - basically I am using simple code to
document wtf code.

~~~
quadhome
One thing I've done is use those original functions as reference
implementations.

Then, in the tests, have a set of sanity check calls to both the original
functions and the optimized versions.

If ever they differ, the tests fail.

What do you think?

~~~
worldsayshi
Nice, this also ensure that the reference code stays up to date. Seeing as
comments that are meant to explain could just as well be a source of confusion
because of neglect.

------
deevus
Some many times this. I absolutely hate seeing commented out code. There's a
reason we use source control.

If a developer doesn't want to lose code they've deleted they can tag the
revision in their repo so they can always get back to it quickly if needed.

~~~
Joeboy
> Some many times this. I absolutely hate seeing commented out code. There's a
> reason we use source control.

How is an unfamiliar developer supposed to find out that the deleted code
exists?

~~~
antonpirker
Why should he/she want to find out?

~~~
Joeboy
In my day job, I sometimes get told to make changes that I suspect will cause
problems in some edge case which we might not see for months. It seems like
the responsible thing to do is to leave the trustworthy version of the code
there for the benefit of whoever has to fix the problem when the shit hits the
fan.

~~~
darklajid
I understand that reality is more complex than this, but

git bisect

That should identify the/your commit in (usually) < 10 tests. At which point
the previous code is still intact.

Or

git blame

and look at the problematic lines, see who changed it and when. Now look at
the git log (filtered just for this file if you want) and identify the last
changes to this part of code that way.

More complex than just

// timestamp, initials: Changed foo, commenting the following 100 lines out

maybe, but makes the day to day code so much more readable.

------
joosters
_Your massive test suite will tell you if you broke something. You have a
massive test suite, haven 't you?_

No!

Your test suite is meant to be a last safety net, there to catch you if you
make a mistake. It's _never_ something to rely upon. Your tests will never be
comprehensive enough. Adopting a 'if the tests pass, all is OK' attitude, as
implied by the article, is a terrible mistake.

~~~
tinco
Not in the Ruby community. And I think dynamic languages in general. Your test
suite should be comprehensive enough to cover something as significant as a
deleted function.

If you maintain the attitude that your test suite is a last safety net, then
you will never be able to confidently refactor, which is what TDD in my
opinion is all about.

~~~
joosters
Yes yes yes, your test suite 'should' be comprehensive enough. But is it? Are
you sure?

Instead of using the tests for confirmation, you should be reasoning about the
code that you are editing to be happy that your changes make sense. Having the
test suites as well is just icing on the cake.

~~~
wlievens
Verifying whether your test suite is comprehensive enough is not that hard in
theory, if you apply mutation testing.

~~~
tinco
It's not that hard in practice either. Besides mutation testing (which becomes
a rather slow affair when your codebase is of significant size) you can just
do coverage checks. If you have a simple branch coverage, that alone can
guarantee (in most situations) which methods are used and which aren't in your
tests.

~~~
wlievens
Actually coveragr only shows you that the code executes, it doesn't tell you
if it's testef.

------
JacksonGariety
The better I get at programming, the more I realize that it's all about the
balance between trimming messy code and avoiding premature optimization.

------
optimusclimb
This was documented 15 years ago, see:

[http://www.antipatterns.com/lavaflow.htm](http://www.antipatterns.com/lavaflow.htm)

~~~
antonpirker
Very cool link! Thank's for sharing!

------
jon2512chua
Good read. But regarding deleting commented out code, I have always have a
strong aversion to doing so even though I really want to, for fear that
someone somewhere might want it.

Has anyone ever faced this dilemma before? If yes how did you guys dealt with
it?

~~~
chill1
I agree with antonpirker here. As long as you're using a version control
system, the code isn't lost. Delete the commented out code, and leave a
helpful commit message along with the deletion. That way the deleted code can
be found, if really necessary.

~~~
jon2512chua
Major do'h moment for me. :P Got so used to using a VCS that I took some
things for granted.

------
ASneakyFox
If you use an ide it will tell you if a function is being used in the project
or not.

------
mantrax4
I find the cognitive dissonance of talking how every line of code is a burden,
yet talking about you needing a "massive test suite" entertaining.

That test suite is also code. How about we go delete some stuff there?

~~~
tinco
Your test suite consists of neatly arranged files containing fully independent
functions, and it is separated from your production source tree.

The only reason it could ever be a burden is that the tests take a lot of time
to run. In which case you could see if there's anything you could optimize,
perhaps only run parts of your suite at any time.

~~~
collyw
And making sure that your tests are correct. I seem to spend as much time
messing about until the tests work, as I do on the code it is testing.

