views:

622

answers:

10

Most programmers will have had the experience of debugging/fixing someone else's code. Sometimes that "someone else's code" is so obfuscated it's bad enough trying to understand what it's doing.

What's the worst (most obfuscated) code you've had to debug/fix? If you didn't throw it away and recode it from scratch, well why didn't you?

+2  A: 

Spaghetti code PHP CMS system.

Ólafur Waage
A: 

I've had a case of a 300lines function performing input sanitization which missed a certain corner case. It was parsing certain situations manually using IndexOf and Substring plus a lot of inlined variables and constants (looks like the original coder didn't know anything about good practices), and no comment was provided. Throwing it away wasn't feasible due to time constraints and the fact that I didn't have the specification required so rewriting it would've meant understanding the original, but after understanding it fixing it was just quicker. I also added lots of comments, so whoever shall come after me won't feel the same pain taking a look at it...

emaster70
+7  A: 

PHP OSCommerce is enough to say, it is obfuscated code...

SilverNight
+1  A: 

When working on a GWT project, I would reach parts of GWT-compiled obfuscated JS code which wasn't mine.

Now good luck debugging real obfuscated code.

Yuval A
with GWT that should be considered the object code and not source. The two are not equivalent.
mP
+5  A: 
  • a Java class
  • only static methods that manipulates DOM
  • 8000 LOCs
  • long chain of methods that return null on "error": a.b().c().d().e()
  • very long methods (400/500 LOC each)
  • nested if, while, like:

    if (...) {
      for (...) {
        if (...) {
          if (...) {
            while (...) {
              if (...) {
    
  • cut-and-paste oriented programming

  • no exceptions, all exceptions are catched and "handled" using printStackTrace()
  • no unit tests
  • no documentation

I was tempted to throw away and recode... but, after 3 days of hard debugging, I've added the magic if :-)

dfa
lol!! the magic if! gotta love that phrase. I'm in kinda similar situation, except it's a hobby, and I'm throwing away and recoding. There's no magic if in my case.
hasen j
A: 

The Perl statement:

select((select(s),$|=1)[0])

which, at the suggestion of the original author (Randal Schwartz himself, who said he disliked it but nothing else was available at the time), was replaced with something a little more understandable:

IO::Handle->autoflush

Beyond that one-liner, some of the Java JDBC libraries from IBM are obfuscated and all variables and functions are either combinations of the letter 'l' and '1' or single/double characters - very hard to track anything down until you get them all renamed. Needed to do this to track down why they worked fine in IBM's JRE but not Sun's.

paxdiablo
+1  A: 

by default, programmers think someone else's code is obfuscated.

The worse I probably had to do was interpreting what variables i1, i2 j, k, t were in a simple method and they were not counters in 'for' loops.

In all other circumstances I guess the problem area was difficult which made the code look difficult.

Janco
Conversely: by default, programmers think their code is self-documenting and doesn't need commenting.
Jesse Dhillon
A: 

If you're talking about HLL codes, once I was updating project written by a chinese and all comments were chinese (stored in ansii) and it was a horror to understand some code fragments, if you're talking about low level code there were MANY of them (obfuscated, mutated, vm-ed...).

Bartosz Wójcik
A: 

I once had to reverse engineer a Java 1.1 framework that:

  1. Extended event-driven SAX parser classes for every class, even those that didn't parse XML (the overridden methods were simply invoked ad hoc by other code)
  2. Custom runtime exceptions were thrown in lieu of method invocations wherever possible. As a result, most of the business logic landed in a nested series of catch blocks.

If I had to guess, it was probably someone's "smart" idea that method invocations were expensive in Java 1.1, so throwing exceptions for non-exceptional flow control was somehow considered an optimization.

Went through about three bottles of eye drops.

Justin Searls
+1  A: 

I can't remember the full code, but a single part of it remains burned into my memory as something I spend hours trying to understand:

do{
  $tmp = shift unless shift;
  $tmp;
}while($tmp);

I couldn't understand it at first, it looks so useless, then I printed out @_ for a list of arguments, a series of alternating boolean and function names, the code was used in conjunction with a library detection module that changed behaviour if a function was broken, but the code was so badly documented and made of things like that which made no sense without a complete understanding of the full code I gave up and rewrote the whole thing.

scragar