Is it acceptable to have useless code?

Question

I see that some programmers add code that, after all, does not do anything useful. For instance (C#):

[Serializable]
class Foo {
    // ...
    string SerializeMe() {
        return new XmlSerializer(typeof(this)).Serialize(this).ToString(); // serialize to xml (syntax wrong, not important here)
    }
}

The class is marked as Serializable, but the only way it is serialized is by means of XmlSerialization, which does not require that class attribute at all.

I personally hate this kind of useless code, but I see it quite often and I'm curious as to what others think about it. Is this not so serious a flaw after all? Is it common practice in the industry? Or is this just plain bad and should be removed no matter what?

Answer 1

Is think the meaning of useless is that it cannot and will not be used. I also think that an open door is very open.

Answer 2

In a commercial project - I'd say no, especially if someone can de-assemble it for reading and then has a WTF moment.

In a home-project - sure why not, I often keep some snippets for later use.

Answer 3

Well I can't comment this particular piece of code without knowing your background but I personally follow strictly a rule not to have anything in code unless I really need it. Or at least know that it may be useful some day for something I have in mind already now.

Answer 4

My rule of thumb,

If its not used get rid of it.

All surplus comments, attrributes are just noise and help your code to become unreadable. If left there they encourage more surplus code in your code base. So remove it.

Answer 5

Good Source Control means that useless code or code that is no longer required should be removed. It can always be reterieved from the Source Control at a later date.

Answer 6

I try to follow the YAGNI principle, so this bothers me as well.

Answer 7

This is bad code.

Bad code is common practice.

That being said sometimes it is not worth the effort in changing stuff that isn't "broken".

Answer 8

Does it take even a minimal effort to read that additional (useless, as you added) code?

If yes (and I think it is so) then it should not be in the code. Code like this is polluted with extra snippets that are not useful, they are there "just in case".
The "later on refactoring" of these things can be painful, after 6 o 12 months, who is going to remember if that was really used?

Answer 9

Really don't like it.

Because I then spend valuable time trying to figure out why it's there. Assuming that if it's there, it's there for a reason, and if I don't see the reason, then there's a chance I'm missing something important that I should understand before I start messing with the code. It irritates me when I realize that I've just wasted an hour trying to understand why, or what, some snippet of code is doing, that was just left there by some developer too lazy to go back and remove it.

Answer 10

If there is an active plan to use this additional feature, then keep it in.

If you know it will never be used, or if that plan stopped being relevant 6 months ago, then pull it out. I'd comment it out first, then remove it fully later.

I'm in the midst of rescoping a lot of variables that were public but really only need to be protected or private, simply because they don't make sense from an API perspective to be exposed--that and nothing uses them.

Answer 11

Useless one-liner code can and should be removed.

Useless code that took time to write can and should be removed...but people in charge tend to get queasy about this. Perhaps the best solution is to have a ProbablyUselessButWhoKnows project where everyone can check in pointless code that might be used again in two or three years. If nothing else, this way people don't have to feel nervous about deleting it.

(Yes, in theory you can get it out of source control, but old deleted code in source control is not exactly highly discoverable.)