41
votes

So, there are a bunch of questions appearing asking is X evil, is Y evil.

My view is that there are no language constructs, algorithms or whatever which are evil, just ones which are badly used. Hell, if you look hard enough there are even valid uses of goto.

So does absolute evil, that is something which is utterly incompatible with best practice in all instances, exist in programming? And if so what is it? Or is it just bad programmers not knowing when something is appropriate?

Edit: To be clear, I'm not talking about things programmers do (such as not checking return codes or not using version control - they're choices made by bad programmers), I mean tools, languages, statements, whatever which are just bad...

23
  • 21
    Null is evil! The Billion Dollar Mistake programmers.stackexchange.com/questions/22912/… Commented Dec 21, 2010 at 14:51
  • 22
    @Amir Resaei, null is necessary if you cannot know the value at the time the reecord is inserted! The ways to gert around using nulls are far worse.
    – HLGEM
    Commented Dec 21, 2010 at 14:53
  • 4
    @HLGEM: Can you share how alternatives like Haskell's "Maybe" are "far worse"? Commented Dec 21, 2010 at 14:57
  • 24
    200 rep cap per day is truly evil.
    – user8685
    Commented Dec 21, 2010 at 15:07
  • 4
    @HLGEM: This might be true for current SQL-databases, i thought we were talking about programming languages. Commented Dec 21, 2010 at 15:27

40 Answers 40

1
2
1
vote

I think there are evil things in programming, but I don't use the term pejoratively.

Evil is when code pretends to behave in one way, but in reality behaves in a very different fashion, and in a way that hurts a unenlightened rational programmer. I often refer to this as a type of "Magic." Magic is anything who's functionality is "hidden" from the programmer, and it comes in different styles.

Example: in Scheme the functions "car" and "cdr" could be implemented using functions only, however, they are not. Instead they are implemented at a lower level imperatively because that runs faster on most computers. I'd call this "white magic." Its not evil, but its definitely magic.

By comparison the unique number NAN in Javascript is not equal to any other number... even itself. This is "black magic." I don't want to get into a discussion of why you have NAN in Javascript (or why you have both Infinity and NaN), but you can see why a such a simple concept would be useful to a language with only floating point numbers. However, having a constant number which cannot be tested for in the same way as other constant numbers is not something one would expect. Fortunately Javascript provides isNAN to help solve this issue, but if you are unaware of NaN's unique property you might write the following code and get burned:

if(x == NaN) 

or if you're clever you might try the following with the same results

if(x === NaN)

I joking refer to this as getting "mana burned" (it is magic afterall...).

I realize there are good reasons why you want things which are not numbers to be automatically equal to themselves, but you have to remember that for IEEE floating point numbers NaN has a specific bit sequence and it is similar to other numbers in this respect. If you treat Javascript NaN the way you might treat an IEEE floating point NaN you are liable to get burned. This is both deceptive and frustrating, the former being the reason I refer to this as Evil.

Then again, its possible people think otherwise...

1
  • Your point about NaN's brings up something I see as a limitation in many languages and frameworks: a lack of clearly-distinguished comparison operators, often combined with a misguided notion that different methods of comparison should be expected to yield the same results. For example, with floating-point numbers, I'd like to have both a comparison operator where NaN != NaN, but +0 == -0, and an equivalence operator where any value, including NaN, will be equalivalent to itself, but where +0 and -0 are distinct.
    – supercat
    Commented Oct 6, 2012 at 17:48
1
vote

When the deadline is near, and requirements change, design changes, and you spend 16 hours in office, that is evil.

0
votes

Is anything in programming truly evil? I mean tools, languages, statements, whatever

Nothing on that list is evil. Here is why.

Humans were created as beings with a free will. They may use their powers to go into the dark side or embrace the light side. This choice defines what comes out of their hands.

Now, those tools and frameworks were created by benevolent people who were genuinely trying to make things somehow better with a good will. Consequently, their creations (either successful or not is irrelevant) do not bear the imprint of evil. At the least they are neutral, but not malicious.

Then those tools come into the hands of other individuals. And whatever they do with them depends on those people. Even a debugger could be turned into an evil instrument in the hands of a hacker trying to remove the serial number check in some software.

But it does not redefine in any way the characteristic of the tool. They are all good. Some are more useful, some less. Some dangerous, some less. But still, they are all good and quite useful in certain scenarios.

And if a programmer by a mistake misuses a tool and causes damage, the tool does not become evil. It's just a programmer mistake, lack of knowledge, ignorance, whatever. But without any evil intent.

Bottom line is, all tools are good. We must love them all.

1
  • 1
    I am your father Commented Dec 22, 2010 at 16:13
0
votes

There's no objective absolute evil.

The problem with things like GOTO is that it's awfully hard to USE it in a way that's not nasty. Enough so that it's hard for me sitting right here now to think of an example of GOTO that isn't code smell. But I'm willing to accept that there might be such uses, and that the problem isn't the tool itself but rather the likelihood of its abuse.

1
  • GOTO is nasty where there is an alternative - but there isn't always an alternative (there should be in a modern, high level language, but we don't always get to use modern, high level, languages)
    – Murph
    Commented Dec 21, 2010 at 19:08
0
votes

Some programming instructions / style / conventions are very often misused to make terrible, evil if you will code, but in the hands of a master programmer they can be used in a very elegant fashion, good if you will.

On the other hand I know of nothing that can prevent incompetent or inexperienced programmers from from producing bad, evil if you will code even with the best tools, languages, and so on.

By avoiding often misused elements, such as goto, the hope is that mediocre programmers can avoid the evil and perhaps make it somewhat easier to write good code.

0
votes

Nothing is really evil not even weapons, yet we sometimes consider them as such. However with weapons we usually have a certain level of respect, we are very much aware of their danger and use them with caution; however there are still people too stupid to use them.

The same applies to any tool, the more difficult the consequences of abusing those tools are, the more likely people are abusing them.

In programming everything is more or less virtual, a program is a representation of our thought process and the long term consequences of not understanding something entirely or getting it slightly wrong are a lot harder to determine, then the immediate danger of death we are faced with when handling a gun.

This makes the tools we use and have at our disposal a lot harder to use but it also gives us an easy way to measure the skill of a programmer. The knowledge of when and how to use the tools you have is crucial to become a good programmer. You can always play it safe by restricting the set of tools but just to the guy to whom everything looks like a nail, eventually you will encounter something that no amount of hitting will fix.

0
votes

The only thing 'evil' is thinking that certain programming things are 'evil'. Various approaches - use this technique, dont use that statement, use this methodology, dont use that language, use this 'best practice', etc - are opinions.

Unfortunately, too many developers mistake opinions for objective truth.

I cringe every time I see a question on here such as 'why is [x] considered evil?'.

0
votes

Everything has it's own valid use, or it wouldn't be implemented. Things are called evil because people do not use it in a safe or proper manner. Consider this...

Is a sword evil? Nope. Just because someone may try to use a sword in a hospital does not mean it is evil. Is a can opener evil? Nope.

Everything has it's proper use. Hence, no evil.

0
votes

Visible side-effects in unexpected places.
In .Net, examples would be ToString(), Equals() / GetHashCode(), property getters, and implicit conversions.
(To be clear, I'm talking about something more than lazy instantiation or logging code)


throw new Exception(ex.Message);

Explanation

0
votes

I agree with the c++ FAQ on this:

[6.16] Will I sometimes use any so-called "evil" constructs?

Of course you will!

One size does not fit all. Stop. Right now, take out a fine-point marker and write on the inside of your glasses: Software Development Is Decision Making. "Think" is not a four-letter word. There are very few "never..." and "always..." rules in software — rules that you can apply without thinking — rules that always work in all situations in all markets — one-size-fits-all rules.

In plain English, you will have to make decisions, and the quality of your decisions will affect the business value of your software. Software development is not mostly about slavishly following rules; it is a matter of thinking and making tradeoffs and choosing. And sometimes you will have to choose between a bunch of bad options. When that happens, the best you can hope for is to choose the least bad of the alternatives, the lesser of the "evils."

You will occasionally use approaches and techniques labeled as "evil." If that makes you uncomfortable, mentally change the word "evil" to "frequently undesirable" (but don't quit your day job to become an author: milquetoast terms like that put people to sleep :-)

1
2

Not the answer you're looking for? Browse other questions tagged or ask your own question.