So something that has been nagging on me both through observations of this website and through my current employer...

Why on earth do engineers obfuscate their code? Is it truly that hard to perform well enough to keep a job?

The only benefits I have noticed from it are... none. Whereas I have countless emails from QA staff to dev's asking "What the heck is this code trying to do" so basically in an attempt to secure your job by presenting a facade of computer savvy you are in fact creating more work, losing your company more money and in actuality becoming a less useful employee...

One man crusade to stop unecessary obfuscation right here :)

These are just my observations - if someone could point me towards a source of information to the exact benefits of it I would be quite happy.

i.e. Does the compiler look at something thats been rendered down to its basest symbolic form any differently than taking the time to actually write "if"? Are there performance benefits? Do they outweigh the problems caused by difficult to read and manage code?

Im just wondering if I am missing out on something important here :)

+2  A: 

Obfuscation is supposed to occur to prevent people from decompiling it (and then perhaps stealing it or making disallowed modifications).

It's not supposed to interfere with development or testing, although obviously the obfuscated version needs to be tested.

It doesn't prevent people from decompiling it nor does it make it harder. It does however make it harder to understand decompiled code.
Filip Ekberg
I guess technically you're right. In fact, they won't know it's obfuscated until they decompile it! However, it is supposed to prevent them from stealing/modifying it by, as you pointed out, making it more difficult to understand. I would call that a difference in semantics, but thanks for pointing that out.
+1  A: 

The only reasonable benefit I've seen: make the distributed code smaller in file size. Proguard can do that for Java.

Obfuscating code with the goal to prevent revealing the original source makes indeed not much sense. Everything is hackable. A smart developer with a smart IDE with nice refactoring/renaming capabilities can already get far.

I'd says thats more packing than actual obfuscation for protection(which generally inceases size with added garbage), things like UPX are easily removed, even just by waiting for the code to unpack its self
+1  A: 

You obfuscate code to make it hard to read, so people can't copy it (or at least to make it more difficult). The trouble with .Net is, because it's bytecode (CIL), it's really easy to decompile DLLs or EXEs (using something like Reflector), so it's easy for people to read your code if it isn't obfuscated.

Grant Crofton
+1  A: 

Obfuscation is more about preventing code from being reverse engineered (perhaps by competitors) than about securing one's own job.

A great example is the .doc file format, which is intentionally obfuscated to make it harder for programs other than Microsoft Word to read them.

I should add that, even if code is obfuscated, that doesn't mean that it can't be reverse-engineered... just that it's harder. Decompilers and other tools serve this purpose.

+1  A: 

Are you asking why 1) developers use obfuscators to make it harder to reverse engineer or 2) why the deliberately write obtuse looking code?

If 1) then it's to somewhat protect the hard work they've put in from being ripped of by a casual hacker (obviously a non causual one can still get it if they try hard ennough)

if 2) then I'm not sure it's deliberate they just probably are that bad. Writing maintainable (i.e. easy to read) code is of very high if not prime importance.


I believe one of the reasons is laziness. Why spend all the extra time to make something clear when something quick and dirty will do the job?

Jesse J
+2  A: 

Why do your developers give obfuscated code to QA? That's very counterproductive for the company. Obfuscating code has uses in making reverse engineering more difficult. For instance, obfuscation can limit (or at least attempt to limit) the distribution of commercial .NET or Java libraries, which are easily reverse engineered by the runtimes' reflection facilities.