Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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...


locked by Thomas Owens Aug 21 '13 at 15:07

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp, bigown Dec 28 '10 at 23:30

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Null is evil! The Billion Dollar Mistake… – Amir Rezaei Dec 21 '10 at 14:51
@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 Dec 21 '10 at 14:53
@HLGEM: Can you share how alternatives like Haskell's "Maybe" are "far worse"? – LennyProgrammers Dec 21 '10 at 14:57
200 rep cap per day is truly evil. – user8685 Dec 21 '10 at 15:07
@HLGEM: This might be true for current SQL-databases, i thought we were talking about programming languages. – LennyProgrammers Dec 21 '10 at 15:27

40 Answers 40

up vote 47 down vote accepted
  1. Magic numbers.
  2. Implicitness is inherently evil, and here's the reason why:
1. there are reason to have them. 2. Type inference in Haskell is a type of implicitness that I love. – Matt Ellen Dec 21 '10 at 14:57
+1 for magic numbers, bane of my life at a very big company. Also, "lost in the distant past" reasons for scaling by 1000 instead of 1024, leading to an enormous overhead in a critical loop that everyone was scared to eliminate because they didn't know what else would be affected. – geekbrit Dec 21 '10 at 15:01
Meh, implicitness is very neat sometimes. Explicitness is for assembly-programmers. – Macke Dec 21 '10 at 18:57
Re #2: I see what you did there...Sorry about the downvotes from people who I'm guessing didn't get the joke. – Larry Coleman Dec 21 '10 at 19:05
@Larry, I got the joke. I just disagree. – JSBձոգչ Dec 21 '10 at 21:44

There is no true evil in programming.


The reason so many people think that there are evil things is that it is pounded into their heads when they first take their programming classes. "Don't use goto! Always normalize your databases! Never, ever use multiple inheritance!" These are hammered in because these "evil" practices are so easily abused, not because they are inherently bad. There are so few uses of them that you can get away with saying "never" at first. What is truly evil is saying, "There is no reason to consider anything that is not a 'best practice'", because there is always a place where that very way is perfect.


+1 - Best practice is a generalisation and for all generalisations there will be exceptions. – Jon Hopkins Dec 21 '10 at 14:47
++ I second your rant. Bravo! – Mike Dunlavey Dec 21 '10 at 14:50
+1: A while back, I added a new goto to some C code I was working on that already had a bunch of them. It was quicker than refactoring it. I told my wife, who's also a programmer, and she asked, "Honey, are you okay? Do you have a fever?" I'm currently working on some code where another guy wrote a C goto that jumps into the middle of a loop. I'd never write it myself, and I curse inwardly every time I see it, but it meets the ultimate test: it works. – Bob Murphy Dec 21 '10 at 16:23
+1 - I worked on some C code right out of school where "goto exit" or "goto error_exit" was used often. I have to say it made for cleaner looking code than, having multiple return statements. My motto is that everything has it's place. (even singletons ;-) ) – eSniff Dec 22 '10 at 1:48
@JonHopkins -- which is why I much prefer to talk of "good practices". – Richard Dec 22 '10 at 9:43

Guns dont kill people, people kill people.

In the same way, dev-tools are not evil, the things programmers do with them could be.

That's a great analogy. – Maxim Zaslavsky Dec 21 '10 at 20:14
Guns don't kill people. Bullets do. :) – fennec Dec 22 '10 at 4:56
Guns go a long way in helping people kill people. What’s worse, I don’t understand the point you’re trying to make: who ever claimed that dev-tools are evil?! There must be something clever in this answer since it got so many up-votes. But I completely fail to see it. – Konrad Rudolph Dec 22 '10 at 11:22
@fennec bullets don't kill people, people kill people. unless machines have finally become sentient, in which case, I'll be in my bunker. – antony.trupe Dec 22 '10 at 16:04
Guns don't kill people, rappers do. – Jon Hopkins Dec 24 '10 at 9:51

Is anything in programming truly evil?

Absolutely. Failure to use your brain and think about what you're doing and why you're doing it is the root of all programming evil.

+1. But s/think about/understand the implications of/ and this would be even better. – Richard Dec 22 '10 at 9:44
Human stupidity is not finite according to Einstein. – Nils Dec 22 '10 at 21:04

Empty generic exception handlers i.e. :

catch(Exception ex)

I don't doubt that someone can give me a valid use case - but, to be honest, its going to be seriously creative... and at the very least you need an explanation.

+1 I was going to add this if someone else hadn't – Conrad Frix Dec 21 '10 at 22:22
Really? "I don't care if this fails or not" is never valid, not in any possible context? Not everything done needs to be guaranteed to succeed or fail, especially in small throwaway utilities. Another case where not thinking first is the real evil. – SilverbackNet Dec 21 '10 at 23:02
I see that in legacy code All. The. Time. What's worse is that people question me when I change it. – George Stocker Dec 22 '10 at 2:01
I add a email notification in it first that sends me a "empty catch block hit" type exception, and release it to prod so I can see WHY that catch is actually there, and under what conditions it's being it. Then I fix it. – CaffGeek Dec 22 '10 at 5:35
I would vote for checked exceptions in Java :D – Nils Dec 22 '10 at 21:05

Perhaps I can flip the question around, and ask if there is anything in programming that is absolutely and perfectly good? If you can't think of one thing (I know I can't), then the concept of evil is also just as muddy.

There are common behaviors that lead to mistakes, misunderstandings, and other general confusion--but to say that language feature X is inherently evil is to admit that you really don't understand the purpose of feature X.

There are common behaviors that can save a lot of heartache and avoid some misunderstandings--but to say that language feature Y is inherently good is to admit that you don't fully understand all the implications of using feature Y.

We are a people of finite understanding, and strong opinions--a dangerous combination. Hyperbole is just a way of expressing our opinions, exagerating facts until they become fiction.

Nevertheless, if I can avoid behaviors that lead to problems and pursue behaviors that avoid them, I just might be a bit more productive. At the end of the day that's what it's all about.

is anything in programming absolutely and perfectly good? Clear, well written documentation? – James Dec 21 '10 at 22:22
@James Clear, well-written documentation is often used for an excuse of unreadable code, and can become shackles that needs to be maintained together with the code if it's overdone. Clear, well-written, but completely outdated documentation can also become pure evil. – Eugene Yokota Dec 21 '10 at 22:49
Working code!!! – Scott Whitlock Dec 22 '10 at 21:25
A comment that explains why. That is good. – Tim Williscroft Dec 23 '10 at 5:22
Ask a few different developers whether the same code is good or bad, and you will get different answers. To say it is absolutely good then would be somewhat inaccurate. – Berin Loritsch Dec 23 '10 at 11:14

I think skinning, auto-updaters that perpetually sit in the systray, applications that hijack file associations and other system settings, are straight evil.

Along with flash-only websites.

so, you're telling me Adobe is evil? – David Murdoch Dec 21 '10 at 18:38
@David: What, you didn't already know that? – Mason Wheeler Dec 21 '10 at 18:47
Worst culprit for file association hijacking is QuickTime I would say. – Orbling Dec 21 '10 at 23:15
For a second I thought you were talking about RealPlayer. (Proud new user of VLC!) – Mateen Ulhaq Mar 30 '11 at 22:43
I'm coming to the conclusion that pretty much anything that Adobe and Apple do is evil. – Brian Knoblauch Jul 17 '12 at 12:41

The only thing that springs to mind is this:


But once again, that's just plain old misuse hehe.

does this macro makes everything FALSE and TRUE into TRUE? – Display Name Dec 22 '10 at 10:19
@bold: I actually ran into that some years ago; thanks to some garbled macro definitions, both TRUE and FALSE wound up evaluating to the same value (0, IIRC). Made for an interesting afternoon. – John Bode Dec 22 '10 at 17:29
@bold Or is it the other way around? – Mateen Ulhaq Mar 30 '11 at 22:44

Everything that happens to work just by accident is inherently evil.

Let's consider the following C program, which happens to actually work on my machine, using default compiler options:

#include <stdio.h>
int main(int argc, char *argv[]) {
   char string[10];
   int y;
   for (y=0; y<10; string[12]++) {
      printf("%d\n", y);   

Nothing, really nothing could ever excuse the way this program increments the loop counter. It's just a undefined effect that happens to do the right thing on my machine, my compiler, my default options.

Nice. Good example - took me a sec to figure it out! Cool. – Michael K Dec 21 '10 at 15:50
I think this is more inherently wrong than it is inherently evil. – Lawrence Dol Dec 21 '10 at 18:55
Fixed a typo in the format string – user281377 Dec 21 '10 at 19:00
Mel would be proud. – Barry Brown Dec 21 '10 at 22:12
I think it's pretty cool, pretty much the same way that structs are used to overlay data structures in assembler calls. Obviously unintentional here, but then you intended it for the example. Power corrupts, up to the wielder to use it properly. NB. That would make an excellent interview question. – Orbling Dec 21 '10 at 23:14
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?

Yes; the standard C library function gets(). It's evil enough that the C standards committee has officially deprecated it, and it is expected to be gone from the next version of the standard. The mayhem caused by that one library call is scarier than the prospect of breaking 30+ years' worth of legacy code -- that's how evil it is.

For those of us who don't speak C care to elaborate on why it's so evil? – Jon Hopkins Dec 22 '10 at 9:12
gets() takes a single argument, which is the address of a buffer. Characters are read from standard input into the buffer until a newline is seen. Because all it receives is the address of the buffer, gets() has no idea how big the buffer is. If the buffer is sized for 10 characters and the input stream contains 100, those extra 90 characters are written to the memory immediately following the buffer, potentially clobbering the stack. As a result, it's a favored malware exploit. It is unsafe and insecure by design. – John Bode Dec 22 '10 at 15:28

Easy, IBM Rational ClearCase is an atrocity.


Null is the root of Evil!

Null References, The Billion Dollar Mistake

The Billion Dollar Mistake: I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965. C.A.R. Hoare, 2009

Amir, obviously a lot of people don’t get this (as evidenced by HLGEM’s comment below the question, and by the low number of votes you have received). Since nullable references are so ingrained in our thinking, it may be hard to realize that they aren’t really natural. So maybe you should explain how the alternatives work, or at least link to articles that do. – If people understood your answer, I’m pretty sure it would be one of the highest ranked here, since the point you made is 100% valid. – Konrad Rudolph Dec 22 '10 at 15:16
@Konrad Rudolph There are answers regarding this under the "Null References, The Billion Dollar Mistake" that I have sent. There are languages that have removed support for Null. – Amir Rezaei Dec 22 '10 at 15:21
+1 the sad truth is that most programmers have no idea about the alternatives. I'm not against the existence of null references, just the notion that it means something. It's simply a pointer that points to an invalid memory location - nothing more. Most programmers treat it as having some meaning in the domain (eg the middle name field is not required, therefore it can be null). In my programs null carries no additional meaning on top of what is specified in the language specification. To me a null reference is always an error. If a field is optional, I use the appropriate option type. – MattDavey Aug 1 '12 at 9:28
@AmirRezaei: What should be done with references which come into existence before there is anything useful for them to point at? I would suggest that it is better to have such references point to something which can obviously not be dereferenced, than require that they point to an object which could be dereferenced legally but not usefully. While there are times it's useful to have references declared in a fashion that requires that they be initialized before anything can see them, requiring that to always be the case would create chicken-and-egg problems. – supercat Oct 6 '12 at 18:14

So does absolute evil, that is something which is utterly incompatible with best practice in all instances, exist in programming?

Of course not. It's like asking if anything in my toolbox is evil. My hammer is a great "good" to me, unless my four year old gets her hands on it.

I think that its even worse when an old man with full use of his capabilities uses it to damage something good. – guiman Dec 21 '10 at 14:51

Today's evil was yesterdays perfect. It's evolution.

GOTO is an anti-example of this, are are magic numbers. – James Dec 21 '10 at 22:23

Copy-paste code.

If you don't itch when you are doing that, you are not a real programmer.

Implicit in the answer: all real programmers have made copypasta anyway, so they know how it feels... – comingstorm Feb 10 '12 at 19:23

Not to be too serious, but ...

We have very myopic views of "evil". People who kill lots of other people are evil. People who steal from others are evil. Every nation (that I know of) has some evil in their past. Some would like to deny it.

Is there evil in programming? We innocent programmers might like to think "not really". However, once I had a conversation with the inventor of a widely-used hierarchical database, on this very subject. Want to know who was one of the best customers? The secret police of Communist Poland.

Is there evil in the world now? You bet. And are they using programmers? You bet.

Possibly a more evil variant of evil than I was thinking. By comparison with the secret police we're really just talking naughty. – Jon Hopkins Dec 21 '10 at 16:56
@Jon: ... and in this season everybody knows "naughty" and "nice" go together :) – Mike Dunlavey Dec 21 '10 at 18:06
Genocide is always truly evil, I feel differently about theft. Stealing, although it hurts others is not the intention, but to improve ones own outcome. If the thief could easily improve their outcome without hurting that of whom they are stealing from they might. I consider this immoral but not truly evil. – JD Isaacks Dec 21 '10 at 18:50
@John: Robin Hood? I know what you mean. In fact, Pareto Efficiency is all about that, I think. It's the opposite of popular theory today. OMG, I hope this doesn't start a flame war... – Mike Dunlavey Dec 21 '10 at 18:56
@John Isaacks - So you're saying that a thief who makes, say, $6,000 in one hour time by stealing a car from an average programmer who works for say, two months to make $6,000 is only "correcting the imbalance"?! Or could it be that some people like thief in question simply assume they are better than others, so they don't have to work hard? – Jas Dec 21 '10 at 19:50

I'm surprised no one has floated Globals as a true evil. No better way to be programming in an environment about which you have no idea of the parameters and virtually no control over what happens to them. Chaos! I have a strict ban on the use of global variables in all of my coding.

+1000 I'd vote this up higher if I could. Single biggest problem in programming today. And countless articles, dialog, and effort goes into educating people about the problem and I don't think it ever changes. Everyone starts out using them as beginners and seldom see a problem with them. Almost every project I come into in a professional settings suffers from over used globals (minus Spring based projects -- mostly). Although you gotta love it when you find BlahBlahManager.getInstance() in a Spring project. Bought the book, still didn't get it. – chubbsondubs Dec 22 '10 at 2:31
Find me a non-trivial application that doesn't have globals. Oh they're wrapped up and neater and protected and in a class and in a framework and generally better... but if there's just one for the application its a pretty much global. Where the issue is is with use of inappropriately scoped variables. – Murph Dec 22 '10 at 9:23
Global variables don't deserve such a bad reputation. Like @Murph said, some things are global. The file system is global (all processes use the same); your process is global to all the threads; the memory is global (another process can use up your memory and crash you while he safely use memory parachute); the user himself is global (think in terms of UI design). It's not wrong to model something inherently global as global variables -- or Singleton, or Service Locator or maybe Registry. – kizzx2 Dec 22 '10 at 18:09

I personally find Donald Knuth's phrase: "premature optimization is the root of all evil" as the first evil thing in programming. In an expirienced point of view (that says that i have failed for this).

Actually, the phrase says something like: Don't try to understand the problem in a particular enviroment, particular PC or set of users before you get in deep into the problem.


Redundant code is very very evil.


What does the FAQ mean by "such and such is evil"?

It means such and such is something you should avoid most of the time, but not something you should avoid all the time. For example, you will end up using these "evil" things whenever they are "the least evil of the evil alternatives." It's a joke, okay? Don't take it too seriously.


Well, I thought Microsoft is/was considered evil and now recently Oracle is the most evil thing in the world.

-1 This isn't constructive or relevant. – adamk Dec 22 '10 at 15:30

I know i said i wouldnt make a post but i'll write one answer. As much as everyone else says no there are no evils i'll say yes there are some absolute evils

Setjmp/LongJmp is pure evil.

+1 I have yet to see a proper use case for Setjmp/LongJmp. – Oliver Weiler Dec 22 '10 at 1:26
@Helper Method: haha, thanks. I am glad someone agrees with me – acidzombie24 Dec 22 '10 at 3:14
try/finally/catch+throw are implemented via Setjmp+LongJmp. – comonad Dec 22 '10 at 10:41
SetJmp+LongJmp can be used to realize CPS (Continuation passing style) via Tail Calls using languages/compilers without PTC (Proper tail calls). It is an optimized version of trampolining.see and – comonad Dec 24 '10 at 9:19
Even more evil than setjmp/longjmp is using setjmp/longjmp to implement a poor man's super lightweight threading library (as I've seen done way back in the DOS days). Delightfully evil code! :-) – Brian Knoblauch Jul 17 '12 at 12:45

Though any tool can be used for good and evil, some tools are evil because they often surprise programmers who don't use them frequently.

I consider the unsigned right shift operator (>>>) in Java evil (surprisingly improper) when working with integers that are shorter than 32 bit.

Say you have a byte b with value -1.

byte b = -1;  // binary: 1111 1111

The unsigned right shift operator shifts zeroes into the leftmost bits. So one assumes a shift by 7 to result in 1.

b >>>= 7;  // binary: 0000 0001 ?

But instead this operation does nothing at all. b is still -1.

Even all of the following 25 shifts do nothing:

byte b = -1;
for (int i = 0; i < 25; ++i) {
    b >>>= i;
    System.out.println(b); // always outputs -1

This happens because b>>>=7 roughly translates to

                                  1111 1111

1) the byte gets widened to a 32 bit int to make shifting possible
    1111 1111 1111 1111 1111 1111 1111 1111

2) the shift happens
    0000 0001 1111 1111 1111 1111 1111 1111

3) the resulting int gets narrowed to a byte again
                                  1111 1111

You would have to replace

b >>>= i;


b = (b & 0xFF) >>> (i % 8);     // >> would also work this time

to make it work as 'expected'.

i dont know java but why is this evil? are you saying it should only be used on ints and byte isnt an int? I find >>> a but weird since i know it as D's unsigned shift right which should not result in a -1. – acidzombie24 Dec 21 '10 at 21:52
@acidzombie24 Absolutely correct. >>> is an unsigned shift and >> is a signed shift. But when shifting a byte it first gets extended to an int (filled up with the sign) and then shifted. So even the 'unsigned' shift extends it with its sign. In fact the result is a positive int but after storing it into a byte it's negative again. – Robert Dec 21 '10 at 22:14
whoa, that is kind of evil. Or at least very likely to give you unintended results. I'm just thinking cant it apply the shift to a byte? if not converting it to an int and back is... not good. – acidzombie24 Dec 21 '10 at 22:32
@acidzombie24 There is no machine code for doing anything with bytes (except loading/storing). On the JVM level 32 bit is the smallest unit. So all the work has to be done either by the compiler or by the programmer. The compiler won't change. I've added the needed adjustment to my post. – Robert Dec 21 '10 at 22:56

No tool is inherently evil. Its existence may be utterly foolish for all but a single use case but that does not make it evil. It puts the onus of deciding the proper use on the programmer.


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 - code should be transparent. – Michael K Dec 22 '10 at 15:02
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 Oct 6 '12 at 17:48

I'm gonna turn this around and say that while there's no absolute evil, there are tools and constructs which make it more plausible for our feeble humans with such a limited skull size to make mistakes than others.

So I'd say you could talk about the evilness of a construct based on how likely people are to make mistakes with it. Sure you can cut bread with a knife or with a chainsaw with blades as grip, but one is more likely to cause damage than the other, even though you may be able to pull it off with enough care.


Code in your native language (not English), write documentation in your native language. And then outsource the project to an Indian company.

That's evil for you!

P.S.: For the record, it happened, and the Indians didn't find it very funny.

Maybe they should have conducted business in such a way that they understood that before they took on the project... – Merlyn Morgan-Graham Dec 22 '10 at 1:01
How would they even expect that? Do you think it's good to have non-english code/documentation in a global sense? – k25 Jul 13 '11 at 16:34

I'm tempted to say continuations, but I think the correct answer is that there is no objective, absolute evil in programming. On the other hand, even the best tools can be abused.

Not many people understand continuations much less had a chance to use them extensively. What situations have you encountered that convinced you they were evil? The one instance where continuations really change the game is asynchronous programming ,especially in UI programming, where you have to keep pumping events so your UI doesn't freeze up. Asynchronous programming causes all sorts of headaches because reuse works really well in synchronous style development. Continuations can be used to restore synchronous style but keep it from freezing the UI. That's pretty awesome. – chubbsondubs Dec 22 '10 at 2:41
I don't think continuations are evil, but I think plenty in the community might, given that any code written using them will automatically be "clever." – Larry Coleman Dec 22 '10 at 10:59

Programming, per se, I think, is not inherently evil. However, programming is very often a social activity, and disrespecting those around you can be very evil. People often forget that most code is going to be shared with others; mostly read, sometimes written too. Be it open source, a product that a company is releasing, or a small piece of patching up a consultant is hired for, programs are going to be read.

That's half the reason why so many "considered harmful" articles exist, or why people say "never". Making life difficult for others is the very root of all evil. Isn't it?


Yes, there is plenty of evil to be had. For example:

Type1 variable1 = function12()
variable5 = variable1.myMethod(variable1+aGlobal);

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