• (cs) in reply to dubwai

    Also, how about trapping all (including fatal) exceptions and instead return NULL's all the back to the front end which then attempts to use properties or methods on the null object. It's kinda the head-in-sand approach to exceptions. lemme tell ya, it's real fun to debug when all you know is a null object exception has occured, if you even get that much info.

  • (cs) in reply to Justin Sippel

    Anonymous:
    This is my favorite kind of WTF: the time-release WTF. Like the above poster, I had to stare for a while before I saw what the author was trying to do, and then came a steady stream of realizations as to how bad this code really is. It doesn't hit you all at once; it's like drinking fine whiskey instead of chugging shots.

    actually, i'd say it's more like drinking a full bottle of slow acting poision, then reading the label...

  • Perfect (unregistered) in reply to j99

    Hahaha! <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    I join you brothers in proclaiming myself both cooler and smarter than he is.<o:p></o:p>

    What an affirmation of our existence to see with incontrovertible proof how much better than him we are.<o:p></o:p>

     <o:p></o:p>

    I ridicule, therefore I am! - Descartes<o:p></o:p>

     

     

  • (cs) in reply to dubwai
    dubwai:

    Charles Nadolski:
    I meant several hundred, not several thousand.  My bad.

    There is a single class in our source code that is just under 10,000 lines.  I shit you not.



    A few quotes from the "Bad Code" page on Ward's Wiki:


    A piece of code that became legendary was a Java method of 230 lines that was passed 17 parameters, returned a string and consisted of nested ifs (5 or 6 deep in places). Now, depending on various magical conditions of some of the arguments, the method would either return null, return a string that was built up throughout the method, or write strings to one of the arguments which was an output stream (in which case the returned string was a meaningless fragment of the output). This method had a CyclomaticComplexityMetric of 150.

    It didn't end there of course, depending on further combinations of the arguments the string itself was either XML, HTML or something else that I've never fully understood.

    The xml was also interesting. Its root element was <thexml>.


    I can remember some wonderful examples from when I used to work with </thexml>GenuineEngineers<thexml> in a University Department. Two that stick in my mind are:

    The C command line parser for user input that consisted of a 5000 line nested if-then-else statement. It was a good thing that tabs were set to 2 spaces, since some of the lines started in column 70.

    Some of the Fortran code - I've still got, in a piece of incredulous email I sent to a friend in 1995, one of the functions that took [292] parameters.



    I was recently hired by a client to try to optimize a huge VB6 application. A windows explorer search on all VB source files which can contain code (*.bas;*.cls;*.frm + a couple of more unusual ones) gave me 20MB! One of the VB projects contains 13 classes. A rather small project would you think? The file sizes are 2k x 5, 4k x 4, 5k, 6k, 40k and (hold your breath) 1,474k!!!

    Aivosto has a nice VB project analyzer, the various reports reveals the following of that giant class: </thexml>

    • There are 309 dead code related 309 problems, most of them are dead variables or variables only written to (how is it even possible?)
    • total logical line count is 29,251 - 8,449 of them are comments - 4,252 are white space. You would think well, at least this beast is well documented. Dream on! Most of the comments are out-commented code which should be removed. The rest is empty function headers, wrong function headers, meaningless function headers and uninforming block descriptions.
    • 20 public and 303 private procedures. Average size is 92 lines, the largest has 501 lines
    • Half of it has a CyclomaticComplexityMetric from 1 - 5, which isn't bad (I guess), but a third of it ranges from 6 - 15, while the rest lies between 16 to 51+. This is bad.
    • Max depth of conditional nesting is 16! I am not even attempting to guess what this one does, or should do.
    • 73% has a structural fan-in of 0 - 1, which indicates almost no reuse. This is an achievment in itself.
    The page also has examples of switch-case and many other common WTFs. reading through it can bring a strong man to tears.

  • (cs) in reply to Schol-R-LEA
    Schol-R-LEA:
    The page also has examples of switch-case and many other common WTFs. reading through it can bring a strong man to tears.


    Aggh! I meant 'for-case', not 'switch-case' (which is a valid construct, at least in C and it's descendants). The specific instance I had in mind was:


      for (int i = 0; i < 3; i++)
      {
    	switch (i)
    	{
    	case 0:
    	DoThing1();
    	break;
    	case 1:
    	DoThing2();
    	break;
    	case 2:
    	DoThing3();
    	break;
    	}
      }


    <font size="4">There is also the </font>EvilCode <font size="4">page, but that's different; those are examples of intentionally bad code.</font>
  • Derek (unregistered) in reply to dubwai
    dubwai:
    There is a single class in our source code that is just under 10,000 lines.  I shit you not.


    That's it?  I'm looking at one at the company I work for having 40,000 lines in a single class.

    Actually, that's not quite correct.  They split out several other definition files for this class, which brings the true total up to just above 60,000.
  • Z (unregistered) in reply to benjymous
    benjymous:
    Part of the Microsoft XML Core Services - msxml2.h has 27782 (utterly unreadable) lines... It seems to be machine generated, which I guess is a bit of a wtf in itself!


    Of course machine-generated code isn't a wtf, it is sane practice for usable code.
  • (cs) in reply to dubwai
    dubwai:
    What I really don't get about this is that there is so much more work (and thought) involved to do this intead of the obvious and short way.  Is it just me or do some programmers think that writing arcane code makes them better programmers?

    They've been studying...
  • (cs) in reply to dubwai
    dubwai:
    What I really don't get about this is that there is so much more work (and thought) involved to do this intead of the obvious and short way.  Is it just me or do some programmers think that writing arcane code makes them better programmers?
    They've been studying...
  • (cs) in reply to yawmark

    Cripes. A thousand apologies for the double-post (I can't edit it/them, either).


    Sometimes, I'm my own WTF.

  • Anonymous (unregistered) in reply to fatgeekuk
    fatgeekuk:
    Does this code actually do what was "intended" (sorry about the quotes, but I am finding it difficult to tell exactly what WAS intended)   For this code to work (and bear with me, I am struggling to know what working means for this), the following assumptions have to be valid.   1) "entry_is_valid" must be a routine which inspects the item at the head of the list. having a reference to the list available via global vars (or possibly as an instance or class variable). 2) "RemoveEntry" must take the top entry and store a reference or pointer to this somewhere. and in the process dispose of any entry that is already stored in this reference/pointer 3) process_valid_entry and process_nonvalid_entry must access this reference/pointer as their argument There is such a mix of ways of passing variables and handling items that this is less than clear Naming conventions are not consistent, this clouds the issue. Specifically, I have assumed that "entry_is_valid" is a routine as it is updated nowhere, but the use of "routine()" calls makes me wonder whether the "enter_is_valid" is a variable that is updated somewhere else. Before you can even think of fixing this code, you have to alter the routines and functions it calls to work on a consistent basis. This will assist the rest of the program by reducing reliance on globals and side-effects. Having said all of the above, and taking into account some refactoring of the other routines, I would say that a neater way to implement this would be... (dunno what language this code is in, so please forgive any problems with references/pointers etc) while (!IsListEmpty(List)){    item anItem;     anItem = removeEntry(List);     if entryIsValid(anItem)    {        processValidEntry(anItem);    }    else    {        processInvalidEntry(anItem);    }     destroy(anItem);} Please correct me if I am wrong, or there is a neater way... Don't even know if the above code needs comments. maybe some to say WHAT it is doing and WHY it is doing it, but the HOW would seem to be self explanetory.

    I'm pretty sure that the entire code can be reduced to the following:

    while(!IsListEmpty(List)) { process_notvalid_entry(); RemoveEntry(List); }

    It hinges on the assumption that discoveredEntry is used to flag if an entry is present rather than to store the value of any of the function calls (which, looking at the names / likely side-effects is probably a whole other pile of junk.

  • Right Wing-Nut (unregistered)

    I laughed--I cried--I did both at once. I'm scared. I'm shy. I don't know why. This should happen to a real guy. Aaaaaaaaaaai!

  • Mike (unregistered)

    The assert false is like saying "fuck me, I can't code", but it's in a loop and not contained in an if/else, switch or anything conditional. Just bizarre. It never should have been a loop in the first place.

Leave a comment on “From WTF to -ism ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article