
It Takes Courage To Delete Code - hdragomir
http://horia.me/on-deleting-code?utm_source=hn
======
pilif
Well. There's two reasons to delete code. One is to delete code you think is
unused or better rewritten. In this case you have unit tests and your source
control system that keeps the deleted lines forever and makes it more or less
easy to get them back.

But if you want to delete code that's in use, that's different. You know: The
code might be some rarely used feature, something added for one customers
request or something that a lot of people once wanted but is now solved in a
much better way but might still have some users.

In that case, removing the code certainly takes courage. Can you explain why
the feature is gone? Can your users/customers live with the feature being gone
(even though there might be a better replacement, they might be used to the
old ways)?

Feature-creep is the most common case for unwanted code, bugs and
maintainability issues.

It feels great though once you show the courage to remove the cruft and then
you can look at lines over lines of red code (my diff highlights removed lines
in red).

~~~
hdragomir
I was talking deleting code that's about to be rewritten, or that just doesn't
work, but this is a great twist!

When taking out a feature, I don't think of it as code (unless a feature is
dragging the app's performance to the ground). So I take it up with the person
in charge (sometimes, that's me) and urge the approval of its removal.

Taking care of users is the fun part -- because if people are furious about a
missing feature, they're passionate about what you're building. Nothing
compares to that, eh?

------
smikhanov
No it doesn't. Your version control system will keep the deleted piece for you
forever.

In the examples the OP is giving, the purpose of code comments is storing the
snippets of the earlier code the developer might eventually need. No matter
which VCS you use, it is better suited for that purpose. There's nothing
heroic about that, so yes, go ahead and delete that piece.

~~~
billybob
Yes. When I first started using version control, the freedom to refactor and
delete old code confidently was a thrill. These days, even a tiny, short-term
project can get the benefit of version control; it's as simple as `git init`.
There's no reason to leave commented-out code in a file anymore.

------
pwim
A developer who needs courage to delete code is probably doing things wrong in
the first place. With source control and good testing, you should be able to
delete code without fear.

~~~
Smerity
I agree whole heartedly. When you commit you're free to do drastic
restructuring, leading to better thought out code. In the worst case you can
revert to an earlier stable point but I find that's almost never needed.

This is also a situation where code reviews would help. Unnecessary/redundant
comments are badly considered forms of communication between coders. When
someone is going to review your code critically it forces you to be clear and
concise, otherwise they'll call you out on it.

------
Fargren
Seriously. Once I was assigned to a project with a coworker that commented
code instead of deleting it. I explained to him why this was wrong, he kind of
agreed and deleted some of the commented code as he saw it, but didn't care
much either way. Until at some point, we needed to test a part of the program
without a feature, so we commented the code that was related to it. When the
time came to uncomment that code, we realized we had no quick way to know
which code we had just commented, and what was old stuff that should have been
deleted.

After we finished with that, we took a few hours to remove all the useless
commented code.

------
chrislomax
I think all this is relative. It depends how "low level" the code is. I
appreciate I have it in source control but I will leave it there for a few
builds before getting rid of it. If its closer to the UI in terms of code then
I will generally just get rid. I suppose it depends how much code depends on
that code.

I know if I made a massive change in my httphandler code then I would
definitely comment it out. I would like to be able to go back in, uncomment
and rebuild in the instance old "tried and tested" code needs to be put back
up. You generally do change code for a reason and it's generally to improve or
because you find a bug but if you have had code running on that function for
years and its just cropped up then uncommenting works for me.

Like I say, after a few builds and seeing the new code in action I will delete
it but I think it does serve a purpose.

If you put a line of comment above the code explaining why it is there then
that would help anyone browsing over the comments.

Just my 2 cents

~~~
hdragomir
I do get your point.

I read a comment once: "Uncomment this if the site crashes!" And there was an
SQL query commented just below.

While that does make for pretty bad code, I guess you need to take
circumstances into account. Stuff like "did they have time or budget to fix
the bug the right way?" "Is this piece of code meant to run when testing the
app locally so it doesn't send emails?" And all that jazz.

But, as you pointed out, an explanatory comment does wonders and conveys the
right context for the commented code -- which was my original problem.

Thank you for taking the time to reply, Chris.

------
random42
I could have written this article myself.

For me, it is simple. Code maintainability is of paramount importance, and
you've got all the history in the version control anyways. Comment is not
Code. They are written for humans for maintaining the program, where as code
is written for machine to execute.

No _code_ should be commented. Ever* __. Comments should _only_ contain text
in english (or what ever language you + your collaborators/people you have to
maintain the code in future speak.)

* _Well, Unless you are not using Version control, which is criminally bad. There is absolutely no reason to not use version control._

~~~
chrislomax
I disagree with this. I actually comment out code to show what the end result
would be.

If have a piece of code that iterates over to create the json to make a
gallery object. I have done what the json end result should look like and
commented it out so if anyone comes back in future they can see what I have
done and why I have done it.

I suppose you could argue that the code example is a comment but it is code at
the end of the day

~~~
random42
Why not actually write an example (like a short blog post, containing some
code snippets), in the comment, using the native language, instead of
commenting the live code?

Dont you think it would improve the readability of the code? Sure it takes
slightly more time, (may be 10 extra mins, for a small example), but I can
assure you, a newbie, who is new to the codebase/language, would certainly
appreciate such an example. (I know, I would have.)

~~~
chrislomax
I do it because its inline.

If someone is looking over the code and right above the recursion see's an
example of what I am doing in my eyes makes it more readable.

Don't get me wrong, it's not something I do every day, I may have done it 3 or
4 times in my life but I have done it. I mainly do it for debugging purposes.
If you are stepping through and you can see a string example of the output you
can instantly compare it to your built string of JSON.

I am probably just being pedantic but I can see a use for commenting certain
code. If i blog posted it and changed it then I would need to make an active
effort to update the blog. It would be like maintaining documentation. I can
just update the comment above and be on my way.

I think everyone has their own methods and I'm not saying yours is wrong, I am
just saying I do see a need to put code in comments sometimes.

There are only two devs here though and we know what we are doing, if a noob
came in then to be honest they wouldn't be touching my code until they
understand it anyway

~~~
random42
> I am just saying I do see a need to put code in comments sometimes.

Yup, There are rules, and then, there are rules. The important thing is to
realize what practice makes sense, for the given condition... and _why_.

------
jsankey
Ii doesn't take courage. Just a little experience tells you that code you
delete is less code to maintain. And if you want to build anything non-
trivial, maintainability is absolutely critical.

I _love_ deleting code.

~~~
wladimir
It does courage to remove code if you have to deal with customers or users
that, it turns out, relied on the feature.

A good example of this is Google Docs. In the first version of Docs, it was
possible to change CSS style sheets and make changes to the low-level
document. You could change background colors and so on.

In the rewrite they removed this functionality to achieve "more simplicity".
However, many people were relying on the customizability, so they have a ton
of complaints about the new version.

It appears that the current decision is to keep the old version "forever". Of
course, whether this is true remains to be seen. But the lesson is that even
if you think a certain feature is useless, people might be relying on it.
You're never sure how customers are actually using your program.

So if you "boldly" delete something you might end up maintaining more
versions, have to reinstate the deleted code, or lose customers. I think
that's where the courage comes in.

~~~
random42
No one is arguing for _throwing away_ the code. There is certain amount of
brains, efforts, time and money spent on writing code.

What is argued is, the _active current_ code should be readable. Version
control systems, handle older versions of code very well.

~~~
wladimir
To your users, removing something from the latest release is equivalent to
throwing away the code. Sure, you can trivially bring it back using source
control, but the user can not, so the damage might already be done.

~~~
random42
End users do not get affected by commented code. A more direct and positive
way of making sure that the users do not get affected, would be to be
responsible and actually test the code before putting it in-front of the
users.

~~~
wladimir
Testing doesn't help if you decide to remove a feature on purpose.

Read my post again, would testing have helped Google in this case?

~~~
random42
No it will not. That is a business decision anyways.

I dont think this is what the post is concerned about. It is about the dead
code, developers leave as commented (for some reason), instead of actually
deleting it.

------
lhnz
I comment the code out and leave a dated comment telling myself to delete it
if commenting it out has caused no issues... I think that's a lot nicer than
having to fetch code from a revision control system if you've taken something
out that's important...

And besides if in a couple of weeks there has been no issues as a result of
the refactor it's then very simple to see what to delete.

------
wccrawford
I remember those days. To this day, I still comment out the old code and leave
it until I'm 100% sure of the new code. Hopefully this is -before- I commit to
source control, but sometimes it's not.

Also, shotgun coding isn't a bad thing in itself. Code, then optimize. In
other words, just get it working, then rewrite it better. It's usually faster
and cleaner in the end.

~~~
hdragomir
So long as you DO refactor when you're done. I sometimes write a mess, too --
especially with CSS -- but in the end it's all clean and wrinkle free.

------
jdk
When I was younger or when I started a new project, I liked to think about
productivity in terms of "lines of code written today". Now or when I'm in a
big codebase, I like to measure in terms of "lines of code deleted today".

------
aforty
My question to anyone I catch doing that: Are you saving that code for a rainy
day? The answer then usually varies but more often than not they get the point
and delete it.

~~~
hdragomir
Of course we are. All the changes to the code (or most, because not everyone
likes source control) are kept with your VCS (git, svn, what have you)

Just keep the codebase clean and have a spine!

