• Will (unregistered)

    I don't get it... what's its purpose? It's not just a List<String> equivalent hard coded to fourteen elements (in an incredibly retarded way) is it?

  • (cs)

    It is their business secret. While the competition is stuck at 10, you just turn it up to 14!

    This must have been the result of statistics. Perhaps someone noticed that 10 whatevers weren't enough to do whatever they wanted to do, and did some calculations and realised that they wouldn't need more than 13 whatevers in the company's lifetime, give or take error margin X. To be on the safe side, the business reqs contained the line 'next version must have 14 whatevers' and the programmer duly implemented 14 whatevers.

  • circuit_breaker (unregistered)

    public class PaulaBean {

    public Brillant() { // stuff }

    }

  • Gonzalo (unregistered)

    I now understand.. this is the other half of the brain that Paula has missing...

  • (cs) in reply to Gonzalo
    Gonzalo:
    I now understand.. this is the other half of the brain that Paula has missing...
    quite possibly
  • (cs) in reply to Rohan Prabhu
    Rohan Prabhu:
    when i see people like this getting hired.. i get assurance of a bright career...

    Ummm actually, since management rarely has a clue, if he was convincing on how brilliant it is then he probably got a raise and promotion for "thinking outside the box." That term is pseudo-code for "I'm a management asshole."

  • (cs)

    Obligatory Spinal Tap Quote: "But this one, goes to eleven!"

  • (cs) in reply to Brother Laz
    Brother Laz:
    To be on the safe side, the business reqs contained the line 'next version must have 14 whatevers' and the programmer duly implemented 14 whatevers.

    Nice analysis, but you misspelled "dully". HTH!

  • Anonymous (unregistered) in reply to Lysis
    Lysis:
    Rohan Prabhu:
    when i see people like this getting hired.. i get assurance of a bright career...

    Ummm actually, since management rarely has a clue, if he was convincing on how brilliant it is then he probably got a raise and promotion for "thinking outside the box." That term is pseudo-code for "I'm a management asshole."

    Remember, it's "brillant".

  • (cs) in reply to Csaboka
    Csaboka:
    Hooray!

    Finally, we see someone who has mastered the FOR-CASE paradigm. Actually, he managed to mix it with the OO paradigm, making a new paradigm altogether. All we have to do is name the new paradigm and teach them to the new generations of programmers!

    It's not just a FOR-CASE paradigm. This is an all-new extension - the FOR-CASE-IF paradigm. I'm not sure we're fully appreciating it here!

  • (cs) in reply to Andrew
    Andrew:
    A dynamically-sized array is a Vector.
    Only if you live in the last millenium. For everyone else, it's an ArrayList, or just a List.
  • (cs) in reply to The Outlaw Programmer
    The Outlaw Programmer:
    I'm having a hard time believing this one. I could understand a junior programmer writing, say, the first 20 lines of code. Once they hit the constructor that takes the ArrayList, though, I'm pretty sure everyone would have realized that "hey, the ArrayList is the exact data structure I'm trying to represent!" and stopped immediately.

    My only guess is that this constructor was actually written later by a more experienced developer that was too lazy to actually refactor the code properly. Maybe, for some reason, they were forced to keep this object around and got sick of calling a 14 argument constructor. Still doesn't make fetching the values any easier though...

    On second thought, no, there's no way that this code is real. Must be some kind of bad dream that I'm having...

    Oh, it's real. The world is filled with people who are certain they can manage memory better than Java can. In the last ten years, I've worked with at least eight of them. Why Java and Java alone gets this treatment, I'm not entirely sure. (I have some guesses though.)

    One thing is clear: the golden rule of premature optimization was not a factor here. The optimizing programmer didn't even try ArrayList before concluding that a more "memory efficient" version was needed.

    Whenever I see an attempt to supplant a standard library class, I ask for justification in the form of reproducible benchmarks in the code review.

  • kid_wonder (unregistered)

    Source -> Generate Getters and Setters

    Duh.

  • Unomi (unregistered) in reply to Brother Laz
    Brother Laz:
    It is their business secret. While the competition is stuck at 10, you just turn it up to 14!

    This must have been the result of statistics. Perhaps someone noticed that 10 whatevers weren't enough to do whatever they wanted to do, and did some calculations and realised that they wouldn't need more than 13 whatevers in the company's lifetime, give or take error margin X. To be on the safe side, the business reqs contained the line 'next version must have 14 whatevers' and the programmer duly implemented 14 whatevers.

    If that is the (for-) case, than they are just one-third there, since the answer to all questions is 42....

    • Unomi -
  • Mario (unregistered)

    for (int a=1;a<=params.size();a++) switch (a)

    Aaaaaaaah!

  • Self Aware (unregistered)

    I don't see what the big deal is. This bean can easily be fixed by adding "sie" to the end of all the member variables. Then, nobody would recognize the counting words and it would be totally logical.

    private String onesie = ""; ... private String elevensie = "";

    See, pretty elegant, right?

  • Unbelievable (unregistered)

    Please kill me now.

  • Andrey Vul (unregistered)

    package dailywtf.fixed; public class ListBean { private String list[]; public ListBean() { } public ListBean(String ... list) { if (list == null) this(""); for (int i = 0; i < list.length; i++) this.list[i] = list[i]; } public String getElement(int n) throws ArrayIndexOutOfBoundsException { if (n < 0 || n >= list.length) throw new ArrayIndexOutOfBoundsException(n); return list[n]; } public void setElement(String s, int n) throws ArrayIndexOutOfBoundsException { if (n < 0 || n >= list.length) throw new ArrayIndexOutOfBoundsException(n); list[n] = s; } } Furthermore, OP's coding style of foo { bar; } was an eyesore for me so my replacement has sane indentation and style. Also, why had the OP not used arrays? Strings are objects you dumb-ass! Clearly an array is better. Also I added range exception checking. Had he been my student and I was a teacher, I would've expelled {him | her} from the course.

  • sf (unregistered) in reply to Licky Lindsay
    Licky Lindsay:
    Shenanigans. There is no way this code is real.

    I believe it, although I suspect that it was their lack of JSP skills that drove this design rather than them not knowing how to use collections. Otherwise I'd declare shenanigans as well.

  • horrified (unregistered) in reply to Bosshog

    com.initrodeglobal... I'll make sure to steer clear of that company.

  • Bobman (unregistered)

    HOW do these people ever get a job as a software engineer?

  • (cs)

    Fourteen whatevers should be enough for everyone. I'm pretty sure that within a few years a new design pattern will emerge out of this idea, saying that if you have more that 14 fields or methods in your class, you should refactor.

  • Code Guy (unregistered) in reply to Emphyrio

    Or they could have used the slightly less known

    ArrayList<String> a = new ArrayList<String>(Arrays.asList(new String[] {one, two, three, ...}));

  • darwin (unregistered)

    I just read all the comments, and I'm surprised that everyone missed something that seemed obvious to me.

    The purpose had nothing to do with memory or avoiding using objects. That was clearly just a throw away line to try to justify the monster they had created. The telling comment was the one about using this with JSP. They're probably using Struts but don't know how to access a list. So they (wrongly) think they need to get all their data in an object that has {get|set}Foo method pairs (the JavaBean naming convention) so as to be able to reference it as simply "foo" in the JSP. That's why simply using ArrayList wasn't acceptable to them.

    I was going to add that the ArrayList ctor was broken because it confused 1-based and 0-based indexing, but I didn't notice that although they have the cases labeled 1, 2, 3, ..., 14 they have hardcoded calls to .get(0), .get(1), .get(2), ..., .get(13) in those cases.

    Ugh.

  • Pathway (unregistered) in reply to Bosshog
    Bosshog:
    This code is so elegant, it makes me want to poke out my own eyes with a fourteen pronged fork.

    That fourteen pronged fork is inefficient. Here, try this shovel!

  • minini (unregistered) in reply to Enterprise Architect
    Enterprise Architect:
    I find this class very useful, but it has too many functions, which makes it slow. My improved version (in C++, also for speed):
    #include <string>

    template <int i>
class EnterpriseListBean : public EnterpriseListBean<i-1> {

    Unfortunately that is only guaranteed to work for values of i up to 17 portably (according to ISO14882::2003(e) the minimal supported maximum of an implementation for template recursion is 17)

  • Jesper (unregistered)

    Aargh! Like many of these CodeSOD entries, this makes me want to yank the keyboard from the programmer's hands, type in "delete ListBean.java" and tell him to start over.

  • dkf (unregistered) in reply to Jesper
    Jesper:
    Aargh! Like many of these CodeSOD entries, this makes me want to yank the keyboard from the programmer's hands, type in "delete ListBean.java" and tell him to start over.
    If it was a good old sturdy IBM keyboard, you could use it to beat the programmer to death instead. Which would be doing the world a better favour.
  • Rhialto (unregistered) in reply to Code Guy
    Code Guy:
    Or they could have used the slightly less known

    ArrayList<String> a = new ArrayList<String>(Arrays.asList(new String[] {one, two, three, ...}));

    I've seen several references to ArrayList being "better" than Vector.

    Why would you call an array a List? That is TF!

    If you want efficient direct access a.k.a. subscription (but don't care much about efficiency of adding/removing elements) one uses a vector (a.k.a. array). In the opposite case one uses a list.

  • jeti (unregistered)

    And when you need to set the value at an index provided at runtime, you can use reflection to find the right setter method. Brillant!

  • Chris (unregistered) in reply to Rhialto
    Rhialto:
    Code Guy:
    Or they could have used the slightly less known

    ArrayList<String> a = new ArrayList<String>(Arrays.asList(new String[] {one, two, three, ...}));

    I've seen several references to ArrayList being "better" than Vector.

    Why would you call an array a List? That is TF!

    If you want efficient direct access a.k.a. subscription (but don't care much about efficiency of adding/removing elements) one uses a vector (a.k.a. array). In the opposite case one uses a list.

    Just in case you're being serious, the main difference between Vector and ArrayList since Java 1.2 (so a real long time ago) is that Vector is synchronized. So any instance where only one thread will access your array, ArrayList would be quicker. If you need multithreaded access then you may want to use Vector so you don't need to do your own synchronization.

    Of course there's this snippit in the API for creating a synchronized ArrayList:

    List list = Collections.synchronizedList(new ArrayList(...));
    No idea how that compares to Vector.

  • Gazzonyx (unregistered) in reply to Csaboka

    Not only mixed with an OO paradigm, but without leveraging a single piece of inheritence! (subtext: I see your corporate 31337 speak, and raise you one!) ;)

  • Rhialto (unregistered) in reply to Chris
    Chris:
    Just in case you're being serious,
    I am serious about the naming. It is quite stupid. A SomethingList says that something is a List. Which, according to basic data type properties, is something completely different than an array/vector.

    I'm not that big a fan of C++'s STL, but their basic collection data types, and the associated complexity guarantees, is something they got right.

  • Andrew (unregistered) in reply to Bosshog
    Bosshog:
    This code is so elegant, it makes me want to poke out my own eyes with a fourteen pronged fork.

    Why not a spoon cousin?

  • Andrew (unregistered)

    The Exorcisim of ListBean:

    I am 1, 2, 3, 4, 5, 6, 7, 8, entry, 10, 11, 12 ,13, 14

  • ishnid (unregistered)

    Can't wait until the next CodeSOD, where we'll be shown how they went about iterating over the thing!

  • (cs) in reply to Rhialto
    Rhialto:
    I am serious about the naming. It is quite stupid. A SomethingList says that something is a List. Which, according to basic data type properties, is something completely different than an array/vector.

    I'm not that big a fan of C++'s STL, but their basic collection data types, and the associated complexity guarantees, is something they got right.

    An ArrayList is an implementation of List which is backed by an array.

    What would you call it?

  • Andrey Vul (unregistered) in reply to VGR
    VGR:
    Rhialto:
    I am serious about the naming. It is quite stupid. A SomethingList says that something is a List. Which, according to basic data type properties, is something completely different than an array/vector.

    I'm not that big a fan of C++'s STL, but their basic collection data types, and the associated complexity guarantees, is something they got right.

    An ArrayList is an implementation of List which is backed by an array.

    What would you call it?

    I would call it Java API redundancy.

  • (cs) in reply to bd
    bd:
    Pay special attention to the constructor that takes ArrayList. If you squint a bit, it looks like a Duff's device. Or in this case, Dufus' device.

    Duff's device or Duff Beer?

  • Lucas Gabriel Sanchez (unregistered)

    I'm not the best programmer of the world, but I think that maybe, that code can be improved using an array.. xD.. WTF!!?? WHO IN THE NAME OF GOD WRITE THIS!!!!.. ¬¬ My grandma can write a better class than ListBeans..

  • Chris (unregistered) in reply to Rhialto
    Rhialto:
    Chris:
    Just in case you're being serious,
    I am serious about the naming. It is quite stupid. A SomethingList says that something is a List. Which, according to basic data type properties, is something completely different than an array/vector.

    I'm not that big a fan of C++'s STL, but their basic collection data types, and the associated complexity guarantees, is something they got right.

    It's an ArrayList because it's an implementation of the List interface that's backed by an array. On insertion, the array is resized (normally by a power of two) if the capacity has been reached. In comparison, LinkedList is an implementation of the List interface that's ... surprise, surprise, backed by a linked list. The choice of which implementation to use usually boils down to whether you're more concerned with random access or insertion into anywhere other than the end of the list.

    As for C++ STL, that's just a WTF. It's predicated on copying, and ends up being a memory hog.

  • Chris (unregistered) in reply to Andrey Vul
    Andrey Vul:
    VGR:
    Rhialto:
    I am serious about the naming. It is quite stupid. A SomethingList says that something is a List. Which, according to basic data type properties, is something completely different than an array/vector.

    I'm not that big a fan of C++'s STL, but their basic collection data types, and the associated complexity guarantees, is something they got right.

    An ArrayList is an implementation of List which is backed by an array.

    What would you call it?

    I would call it Java API redundancy.

    Nope, as I point out above, there are different implementations of the List interface because they exhibit different behaviour. Meanwhile in C++ land, and in keeping with Stroustrup's own obsessions, the STL designers were more concerned with interface elegance than performance. The end result is that I find I have to use my own hand crafted containers for C++ quite often because the STL ones are too generalised to perform adequately.

  • jonl (unregistered) in reply to Bosshog

    I laughed so hard I made a mess in my pants. Nurse get the medication...

  • pepperbob (unregistered)

    Nice! This "solution" is really something that I'd expect from our internal ERP Support Team. I stopped getting upset on this...

  • Rhialto (unregistered) in reply to VGR
    VGR:
    An ArrayList is an implementation of List which is backed by an array.

    What would you call it?

    If it is an array, I would call it an Array. Not a SomethingList, which is a List. (And if it isn't, you can't trust its name,which disqualifies it too.)

    A List which really is an Array, or the other way around, is the worst of both worlds, since you cannot count on the good properties of either.

    I suppose this miserable situation stems from the fact that there is this base-Interface called List and they felt it necessary to keep the name in subclasses. They could have done something more correct in that area.

  • (cs) in reply to Chris
    Chris:
    Meanwhile in C++ land, and in keeping with Stroustrup's own obsessions, the STL designers were more concerned with interface elegance than performance. The end result is that I find I have to use my own hand crafted containers for C++ quite often because the STL ones are too generalised to perform adequately.
    That's a dubious comment on both Stroustrup and on the STL designers. Much as I love both C++ and the STL, I wouldn't suggest that either one is obsessed with "interface elegance." (basic_string, anybody?) On the other hand, C++ is, if anything, too obsessed with performance.

    If you need high-performance from your containers, may I suggest storing pointers instead? Even with my trusty Knuth Vol II at my side, I doubt I can roll a significantly better container than Stepanov et al.

    I suspect that all the copying is more a result of the functional programming background of the STL lot, but I could be wrong.

  • MdK (unregistered) in reply to Bosshog

    And you can eat a Brillant Paula Bean with it afterwards.

  • Ankeet (unregistered) 
    package com.initrodeglobal.util.presentation;

    Keyword being presentation.

    Wouldn't a -normal- programmer get lazy writing that whole mess and just use one of the millions of more efficient ways to do it? I know I would.

  • Gigitrix (unregistered)

    There's an array of witticisms tat I could make here....

  • Andy_randomsuffix (unregistered) in reply to Csaboka

    Surely if you mix the OO paradigm with the FC paradigm your code is totally FOOC-ed ?

Leave a comment on “These Go To Fourteen”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article