Open Source == Quality
-
We've all heard that bit ... because thousands of passionately interested users continuously improve code. Well, the Bile Blog (I suspect there is some overlap between his readers and the WTF) pointed out this 2200 line example of what not to do: DefaultServlet
-
@Stan James said:
...example of what not to do: DefaultServlet
I know nothing about implementing servlets - what's the WTF?
-
Please enlighten us as to what exactly is 'wrong' with the code... I'm sure most of us don't do serverlets, and a good chunk of us don't work with Java either. Far as I can tell, thats fairly easy to follow, decent code.
-
Google is a good thing...
That, I think, is the blog referenced.
-
Java may not suck.
But it's implementation surely does.
-
Tomcat is open source. Tomcat contains horrible code. Therefore, all open source programs contain horrible code.
Brillant!
-
Read the code. The comments add zero information to the code. Many are untrue. It swallows exceptions silently. Methods don't do what the names say. If the hint of a 2200 line Java class doesn't raise a WTF you maybe did too much Fortran. :-) A field called "input" is really "inputBufferSize". Methods that should be idempotent actually have side effects. It doesn't close streams rigorously, even when the comments say it does. It writes HTML ... kinda what JSPs were invented for. There is more with almost every method. A veritable smorgasboard of WTFery.
-
@LuciferSam said:
Google is a good thing...
That, I think, is the blog referenced.
Yup, that's the one. This crowd ought to like the BileBlog. Many wagging penis references and such.
-
@Stan James said:
@LuciferSam said:
Google is a good thing...
That, I think, is the blog referenced.
Yup, that's the one. This crowd ought to like the BileBlog. Many wagging penis references and such.
I am tempted to registrer mywaggingpenis.com
-
A lot of open source projects contain horrible code. But I use
them anyway, not only because I know I can check them for spyware or
other nastiness, but also because I can fix them when necessary.
(And I've had to do so occasionally.)
But the most important reason of all is that even though many open
source software products suck, they don't suck nearly as much as their
proprietary equivalents.
Have you ever looked at the source for the Mozilla products? Not
for the weak of stomach. But I use Mozilla religiously, because
it's far better than IE and Outlook. (Opera is good but I found
being extorted by animated banners a permanent turn-off.)
The Linux kernel contains goto statements. But it can stay up for months, whereas Windows... well, you know.
mplayer is some of the worst-designed software I've seen. But it
plays nearly everything, and anything is better than the ordeal that is
Windows MediaPlayer 8 or later.
It's not universally true, of course; the only way I could argue
that GIMP is better than Photoshop is if I claim that price is part of
what makes a product "good." (That argument may have some merit.)
-
From the blog link:
@BileBlog said:The pain goes on and on, and never really ends with this class. We have an impressive ignorance of how basic numeric handling in java works, as evidenced by // To avoid 0.0 for non-zero file, we bump to 0.1. We also have renderSize and displaySize, both of which do equally fucked up shit.
Eh... Here, look at the block:int leftside = filesize / 1024;
int rightside = (filesize % 1024) / 103; // makes 1 digit
// To avoid 0.0 for non-zero file, we bump to 0.1
if (leftside == 0 && rightside == 0 && filesize != 0)
rightside = 1;
buf.append(leftside).append(".").append(rightside);
buf.append(" KB");
Okay, granted, it's definitely not the best way to round down to a tenth of a KB, but the comment is completely sensical. Notice what happens if filesize=1 (or anything else less than 103):
leftside = 0
rightside = filesize/103 = 0 (x/y with ints is 0 if 0 < x < y)
if - True
rightside = 1
Output: 0.1 KB
Makes perfect sense, even if it is stupid. I'm guessing the blogger didn't notice that we're dealing with ints everywhere.
NB: A better solution:double tkb = filesize / 10240.0; // Tens of kb
double kb = Math.ceil(tkb) / 10.0; // kb rounded to nearest 10th.
buf.append(Double.toString(kb).substring(0,3))
Just appending kb would work if you don't mind the very occasional longer string due to roundoff errors. I'm not even sure that's a problem when dividing an integer by ten, so you might be able to drop it.
Sure, the results aren't exactly the same, but they're clcose enough to work. Swap to floor and check for the oddball case if you're determined to match... though the /103 might throw you since it's not quite a 10th of 1024. It'd take more effort than I care to spend to figure that one out.
-FunnyMan