• (cs)

    Would you call this style of coding, Childish?

  • Gaza Rullz (unregistered)

    Coding : You're doing it wrong.

  • macmac (unregistered)

    Im guilty of having done similar stuff in Javascript. Namely in custom userjs files for opera (greasemonkey for the firefox users), meaning you don't have control over the layout of the original html file you are customizing. You make a userJS file that adds a button that should hide a certain element that has no id and no class defined. The best you can do is find another nearby element that DOES have an ID and do the parent/children thing to get to the right one.

  • Warren (unregistered)

    OK, I see the WTFs. The first one doesn't do anything with the result obtained, and the second one could be optimised to one line rather than using the variable thechkbox.

  • Honnza (unregistered)

    if(hasrating){ $(currRating[0]) .closest("li") .find("input[type=checkbox]") .attr("disabled",false) }

  • The Daily WTF (unregistered)

    Is it really a WTF? I'm not so sure, and I'm The Daily WTF.

  • macmac (unregistered) in reply to Honnza
    Honnza:
    if(hasrating){ $(currRating[0]) .closest("li") .find("input[type=checkbox]") .attr("disabled",false) }

    And now without jquery ;)

  • Bruce W (unregistered)

    It takes a unique type of inbreeding to code like that.

  • imgx64 (unregistered)

    Looks like the elements in the second snippet are second cousins thrice removed.

  • Techpaul (unregistered)

    thetxtbox = comment[10].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.children(Frist).children(Frist0).children(second)

  • (cs) in reply to Honnza
    Honnza:
    if(hasrating){ $(currRating[0]) .closest("li") .find("input[type=checkbox]") .attr("disabled",false) }

    Needs more jQuery!

  • (cs)

    I've done something like this only once and it was for a weird bit of JavaScript in a pre-4.0 ASP.NET WebForms (so the weird-ass control IDs) where using a jQuery selector, for whatever reason, just wouldn't find the element. The only choice was do control.parent().parent().parent().something()

  • (cs)
  • Xarthaneon the Unclear (unregistered) in reply to Bruce W
    Bruce W:
    It takes a unique type of inbreeding to code like that.

    Appalachian Application Development - the next big breakthrough in computer science!

    It's when genetic algorithms go wrong.

  • $$ERR:get_name_fail (unregistered)

    I also wrote code like that a few times when writing bookmarklets.

    When you are operating on HTML code by someone else and perform operations on it the original author never intended, you often have no other choice.

  • TheSHEEEP (unregistered)

    What language is the first one?

    First I thought it was ActionScript, but that one doesn't have the MouseEventArgs type and "object" type is capitalized. Java afaik also has no MouseEventArgs and Object instead of object. .NET has MouseEventArgs, but also Object.

    Seriously, what is this?

  • (cs)

    You always have another choice.

    x = some.really.long.query.string()
    is always bad.

    Even if you're not using jQuery, you are doing queries against the DOM. You should encapsulate those queries, even not for reusability, but for readability.

  • Ben Jammin (unregistered)

    Several people are saying that when one does not have control over the html, that this approach is sometimes necessary. Wouldn't you want something a little more robust; Especially, if you did not have control of the html? All they have to do is mess with their design slightly, and they probably wouldn't even think to notify you that they added pretty boxes around their pictures, and the code is broken.

  • Nick (unregistered) in reply to TheSHEEEP

    "What language is the first one?"

    Probably C# (.NET), it uses object as the default when creating an event handler.

    Most of the common types have lower case keywords you can use instead for convenience.

    e.g. System.Int32 -> int System.Int64 -> long System.Boolean -> bool System.Object -> object System.String -> string

  • (cs) in reply to TheSHEEEP
    TheSHEEEP:
    What language is the first one?

    c#.

    It has syntactical sugar for common .NET types

    object = Object int = Int32 string = String

    etc.

  • Omego2K (unregistered)

    (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType();

    Lets ignore the fact that the code is bad. What is this line supposed to accomplish?

  • WPFWTF (unregistered)

    You have to do this if you're animating subproperties on a part of a template in WPF.

    Of course, it's all right there together, and if you alter the template you'll have to alter the binding anyway.

    but it's more like.

    control.template = some stuff -> new textbox() { text = bind to control's date's yadda yadda field }

  • Brent (unregistered)

    Sadly, I cam empathize with this type of code more than other examples of bad code on this site. The best way I know to find a specific parent on a form like that is with recursion: http://www.kruegerwebdesign.com/blog/find-first-parent-control-of-a-specific-type-using-recursion

  • (cs) in reply to Omego2K
    Omego2K:
    (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType();

    Lets ignore the fact that the code is bad. What is this line supposed to accomplish?

    Allows us to take the piss out of it for one thing.

    It does nothing, the result of GetType() is thrown away.

  • Jamie (unregistered) in reply to jamiec
    jamiec:
    Allows us to take the piss out of it for one thing.

    It does nothing, the result of GetType() is thrown away.

    They also shouldn't be doing (sender as PictureBox) either. If sender is always a PicutureBox, do a direct cast. If it might not be a PictureBox, you've got a situation in which(sender as PictureBox) returns null.

  • (cs) in reply to Jamie

    I think that code might be its own grandpa!

  • the beholder (unregistered) in reply to jamiec
    jamiec:
    Omego2K:
    (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType();

    Lets ignore the fact that the code is bad. What is this line supposed to accomplish?

    Allows us to take the piss out of it for one thing.

    It does nothing, the result of GetType() is thrown away.

    ...unless GetType() has been overridden to do something else other than returning the object's type.

    Naturally that would fall into another category of WTF, probably an even worse one. But hey, at least it would mean that line is not useless.

  • (cs)

    That reminds me of AppleScript Studio. At least with these you can be glad you don't have to specify the parent elements yourself — all the way up the hierarchy …

    set isChecked to value of checkbox "foo" of box "baz" of tab "bar" of tab view "foobar" of window "whatever"
  • jay (unregistered)

    Need it be stated: What's wrong with this code is not that it chases up and down the parent/child tree, but that it builds in the assumption that it is exactly this number of generations. Yes, I've had times when I've had to do something like this. But what I generally do is put a loop that takes parents until it finds a node of a certain type or that has a certain class, rather than hard-coding the number of generations. Then, (a) if someone changes the HTML to add or remove a level of tags, my code doesn't mysteriously break, and (b) someone reading it can see, "Oh, he's getting the enclosing li tag" or whatever, rather than, "Eight levels up? What's eight levels up?" Especially if something went wrong after another programmer added or removed a level of tags, and know someone is trying to figure out where it's supposed to go.

  • Daniel (unregistered)

    There's nothing wrong with this code. Nothing at all. It's a perfectly valid form of adressing a branch within a known inner scope tree encapsulated in an unknown outer scope.

    In fact, it's the right way to do just that. It's called reusability. This was most likely a plugin of sorts.

    The fact that so many of you are dissing it just shows how many chimpanzee wannabe programmers are reading tdwtf.

  • (cs)

    It's the (not so) famous third-cousin design pattern!

  • dahvyd (unregistered) in reply to the beholder

    Can't override Object.GetType() as it's sealed.

  • Fox Mulder (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    I think that code might be its own grandpa!
    And if your aunt was your sister, you'd be your own grandpa.....
  • Robert Heinlein (unregistered)

    That code knows where it came from. But all you zombies, where did you come from?

  • (cs)

    This is positively scary. Talk about your fragile code: "I refactored routine someDumbThing() into two parts, one of which calls the other, and now nothing works. WTF!"

    The only thing I can think of that would be worse would be enhanced reflection along this line:

    ((Victim) caller().caller().caller().getObjectVariable("victimVar")).setStatus("whatever");

    Oh, BTW: I vote "Ancestors" as WTF of the year.

  • QJo (unregistered) in reply to jay
    jay:
    Need it be stated: What's wrong with this code is not that it chases up and down the parent/child tree, but that it builds in the assumption that it is exactly this number of generations. Yes, I've had times when I've had to do something like this. But what I generally do is put a loop that takes parents until it finds a node of a certain type or that has a certain class, rather than hard-coding the number of generations. Then, (a) if someone changes the HTML to add or remove a level of tags, my code doesn't mysteriously break, and (b) someone reading it can see, "Oh, he's getting the enclosing li tag" or whatever, rather than, "Eight levels up? What's eight levels up?" Especially if something went wrong after another programmer added or removed a level of tags, and know someone is trying to figure out where it's supposed to go.
    +1 FTW
  • Meep (unregistered) in reply to Daniel
    Daniel:
    There's nothing wrong with this code. Nothing at all. It's a perfectly valid form of adressing a branch within a known inner scope tree encapsulated in an unknown outer scope.

    In fact, it's the right way to do just that. It's called reusability. This was most likely a plugin of sorts.

    The fact that so many of you are dissing it just shows how many chimpanzee wannabe programmers are reading tdwtf.

    Except that it's not at all reusable. The reusable version would be something like:

    var obj = sender;
while(!(obj instanceof Form)) {
   obj = obj.parent;
}

    Or looking it up using DOM or using a closure when constructing the handler or any of a dozen techniques to pass the information cleanly and reliably.

    If you alter your GUI slightly and have to wade through a slew of bug reports, you're doing it wrong.

  • (cs) in reply to Daniel
    Daniel:
    There's nothing wrong with this code. Nothing at all. It's a perfectly valid form of adressing a branch within a known inner scope tree encapsulated in an unknown outer scope.

    In fact, it's the right way to do just that. It's called reusability. This was most likely a plugin of sorts.

    The fact that so many of you are dissing it just shows how many chimpanzee wannabe programmers are reading tdwtf.

    Awful troll, must try harder. See me after class.

  • (cs) in reply to Daniel
    Daniel:
    There's nothing wrong with this code. Nothing at all.[...] The fact that so many of you are dissing it just shows how many chimpanzee wannabe programmers are reading tdwtf.
    What I like about this posting is the fact that it was posted directly after jay's good post on how to solve the problem in a better way :-)
  • Herr Otto Flick (unregistered) in reply to jay
    jay:
    Need it be stated: What's wrong with this code is not that it chases up and down the parent/child tree, but that it builds in the assumption that it is exactly this number of generations. Yes, I've had times when I've had to do something like this. But what I generally do is put a loop that takes parents until it finds a node of a certain type or that has a certain class, rather than hard-coding the number of generations. Then, (a) if someone changes the HTML to add or remove a level of tags, my code doesn't mysteriously break, and (b) someone reading it can see, "Oh, he's getting the enclosing li tag" or whatever, rather than, "Eight levels up? What's eight levels up?" Especially if something went wrong after another programmer added or removed a level of tags, and know someone is trying to figure out where it's supposed to go.

    Or I could just wait for the offending twatknuckle to check in their breaking change, wait for Jenkins to fuck them up the arse, and then force them to unbreak my code.

    "I know, lets make it much slower just in case someone does something stupid in the future"

  • Worf (unregistered) in reply to Gurth
    Gurth:
    That reminds me of AppleScript Studio. At least with these you can be glad you don't have to specify the parent elements yourself — all the way up the hierarchy … 
    set isChecked to value of checkbox "foo" of box "baz" of tab "bar" of tab view "foobar" of window "whatever"

    Though, if you specify up the hierarchy, it's a lot easier to catch when someone movies something around - you'll get an error. If someone happened to move the control around, the unspecified ones can still work in very odd ways leading to very hard to troubleshoot bugs.

    Of course, it also means the article version can have controls moved around without (apparently) breaking the code.

  • B. D. Johnson (unregistered) in reply to Xarthaneon the Unclear

    So recursive genetic algorithms?

  • panzi (unregistered)

    I don't see how that JavaScript code ever worked. children is not a function but an array (like object - a HTMLCollection) so the parentheses should be replaces with square brackets.

  • (cs) in reply to panzi
    panzi:
    I don't see how that JavaScript code ever worked. children is not a function but an array (like object - a HTMLCollection) so the parentheses should be replaces with square brackets.
    Oh. Must be a scheme, so.

Leave a comment on “Ancestors”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article