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


Log in to reply