views:

592

answers:

10

They may not be pretty, but they work. Sometimes a best-practice has to take a back seat to 'good enough'. What is the best example of a kludge that you've ever seen passed off in code?

+2  A: 

The code for fetchmail (a command-line mail retrieval tool) had hard-coded special cases for certain popular mail servers that don't comply to standard protocols.

The earliest versions of the Netscape browser (maybe when it was called Mosaic?) did client-side load balancing when you access one of their servers.

ie, the browser would actually go to a random mirror of the site when you tried to access it because the browser was hard-coded to recognize that address.

I, personally, have kept javascript functions in a database table, then spit it out into a page to be evaluated at runtime. And I'm only slightly ashamed of that.

HS
+9  A: 

It was something along the lines of:

FILE *fh = fopen ("file.in", "r");
if (fh == NULL) fh = fopen ("file.in", "r");
if (fh == NULL) fh = fopen ("file.in", "r");
if (fh == NULL) return -1;

No, I don't know what they were thinking. Maybe another program could deposit that file on the file system really fast.

paxdiablo
that made me chuckle
Cuga
well...try harder ^^
Scoregraphic
If at first you don't succeed, try, try again.
Sukasa
The question asks for kludges that *work*. You're not convincing me.
Joe White
I've seen something like this before and I know what it was for, not saying this was the case here though: There was a call across a network share that would reliably fail the on the first call but it would trigger the connection so on the very next call the open would succeed.
jwsample
the only explanation I could come up with is: if another program is scanning the disk, occasionally files are locked (antivir programs?). So a retry might help. However, a delay in between is missing. So, I guess, this is garbage to increase the code size (maybe he was payed by lines of code ?).
blabla999
+10  A: 

Most of computer graphics is a big kludge as doing the "right thing" is usually very expensive. A few examples:

Naaff
+1 for computer graphics
Scoregraphic
+3  A: 

One example is that it's not unheard of to not release memory when the process is shutting down (even though it's arguably a "best practice" to release what you allocate), and insead let the O/S reclaim it after the process has gone (which is "good enough").

One could also argue that "good enough" is itself "best practice".

ChrisW
+5  A: 

Does Carmack's fast inverse square root count as a kludge?

Mark Maxham
Maybe, but the code isn't Carmack's. http://www.beyond3d.com/content/articles/8/
Nosredna
+10  A: 

I always loved this one:

// Fixed NPE
try{
...offending code...
} catch (NullPointerException e) {
    // fixed
}

Plain... simple... fixed the "problem", but so not right.

The sad part was that this was in 10 places in the file.

GreenKiwi
Whether that's horrible or not depends entirely on the "...offending code..." part. It may have avoided cluttering everything with 20 different if statements, on the other hand it *may* lead to a corrupted transaction. But if this is a simple "get me a value from somewhere" function: why not?
Udo
Lets just say that this was in the middle of some rather important code. It did give us a bit of a good laugh when we saw it though.
GreenKiwi
for me, that is categorized "worst kludge". It is now completely forbidden in our company. makes bugs almost impossible to find. There is an even more terrible version, though: try ... catch(Exception)
blabla999
+4  A: 

In the source to an old version of WebKit:

m_allowFontSmoothing = (nameStr != "Ahem");

Apparently it was some special casing to say they could pass Acid3.

Zifre
That's just cheating.
PiPeep
+1  A: 

GC.Collect(); //Garbage collection C#

Although I've read everywhere you shouldn't need to use it, I've seen memory issues in two applications where calling this method once in a while resolve the memory problems.

Chris Persichetti
If that fixed the memory issues, then the program has a bug.
Zifre
Both times I've seen it happen was with long looping processes that take up high CPU%. Almost as if GC never has time to collect by itself :(
Chris Persichetti
I used the Java equivalent (`System.gc()`) once, in a game, around 1999. Forcing a GC between loading the level and starting to play it meant that normal GC was less likely to be triggered during play.
finnw
@zifre: you get filedescriptors, if someone forgot to close a stream. Still a bug, but sometimes you get them by using bad code in a dll or jar or whatever, which you cannot fix easily.
blabla999
+4  A: 

Threading is hard, but Application.DoEvents() is real easy!

LoadData();
Application.DoEvents();
PrepareOutputUI();
Application.DoEvents();
// Application.DoEvents();
foreach(var thing in whatever)
{
    Application.DoEvents();
    ProcessThing(thing);
    Application.DoEvents();
}



Application.DoEvents();
mquander
I love the commented `// Application.DoEvents();` placed right after a call to `Application.DoEvents();` like they were calling the function twice in a row at one point.
PiPeep
+5  A: 

In C code:

system("echo Press Return to continue");

Apparently printf() was busted that day and they needed a workaround, even if it involved a fork and exec of another process or two. :-)

Pete TerMaat
Maybe they wanted to make sure they wrote to the console even if STDOUT was redirected?
Joe White
One man's kludge is another man's perfect solution.
Peter M