Representative line



  • From the less horrible of the two projects I've recently inherited:

       private Property property109 = new Property();

     

    Yes, property1 through  property109 all exist.

    No, none of them are ever set or read.



  • I would think the compiler will ignore them.  A bigger WTF would be if they WERE set and read, and were public...



  • I'm pretty sure if that's a representative line that property 109 IS set.



  • I agree with the above.  Too often if a property looks like it is never set or read, then you need to carefully grep through the codebase to see if it is ever accessed via reflection.  Unfortunately some people at my company have discovered how wonderful reflection is at making code that is impossible to navigate via IDE tools - especially when combined with string concatenation .



  • Hey, at least you guys have a compiler to tell you about things like that. In Javascript you may be working with a wall of code that's full of properties which seemingly are never read - and some code analysis tools like JSHint will raise alerts saying so. Then when you chop those off and run the program, it breaks because all those never-assigned, never-read properties are all being used with eval().



  • @Renan said:

    it breaks because all those never-assigned, never-read properties are all being used with eval().
     

    Few things have given me a greater desire to punch someone in the dick than the existence of eval().



  •  eval("var "+ variableName +" = 42;");

     

    :3



  • @dhromed said:

    :3
    Your smiley looks like boobies, and that makes me happy.



  • @indiana83 said:

    accessed via reflection.
    Good god, I think I would nail their hands to their thighs...  Accessing private properties via reflection is just fucking stupid, and should be a sackable offence.

    @indiana83 said:

    Unfortunately some people at my company have discovered how wonderful reflection is at making code that is impossible to navigate via IDE tools - especially when combined with string concatenation.
    Wow, not only are they fans of creating unmaintainable piles of shite, but they also like to make their code as brittle as possible.  You should ask the offender(s) what they think would happen if the private property they're accessing "cleverly" via reflection changed names, or types, or was removed completely...

    This reminds me of someone who knows about the System32 folder, but doesn't know the repercussions of "deleting a bunch of old files" they didn't recognize.



  • @indiana83 said:

    I agree with the above.  Too often if a property looks like it is never set or read, then you need to carefully grep through the codebase to see if it is ever accessed via reflection.  Unfortunately some people at my company have discovered how wonderful reflection is at making code that is impossible to navigate via IDE tools - especially when combined with string concatenation .

    That's a horrifying thought, but it sounds like the sort of thing that could happen in a project where someone with no knowledge or oversight let NetBeans do whatever it wanted.  Most of my certainty that it's not read comes from the fact that the form with those properties has grown enough that, if they were still in use, there ought to be a property171 by now.




  • @C-Octothorpe said:

    ... Accessing private properties via reflection is just fucking stupid, and should be a sackable offence.

    Normally I'd agree, but I recently had to write code to do just that because for some reason our ITree interface (which extends ITree, is implemented by Tree, and contains an SWT Tree instance...) didn't offer any methods to ask about parent / child relationships in the tree. When I asked the guy who wrote it, he told me to "use the dumpToFile() method, read that back in, and parse it". Fortunately, I was writing test code, but still...wtf.

    I work on a seriously over-architected pile of garbage.



  • @Sutherlands said:

    I'm pretty sure if that's a representative line that property 109 IS set.

    yebbut you know what he MEANS ....



  •  I was wrong about none of them ever being set or read; some of them are bound to JSF properties.  The numbering is impressively random, though; one section has properties 71,51, 52, and 53;  this is followed immediately by properties 73, 64, 65, and 66.

     

    I had foolisly hoped that the numbers here were "sensibly" mapped to the insanely denormalized "field_entries" table, where four columns (one of which is just a sequence number) do the job of what should be 15-20 tables (Entity-Attribute-Value, in an application where the potential attributes are strictly defined):  if property 71 were supposed to hold the value for field_id 71, there'd at least be a twisted logic.  But for those two sections, the mapping is

    Screen property   71   51   52   53     73   64   65   66

    Field ID               86   58   56   77     88   57   79   78



  • @DemonWasp said:

    @C-Octothorpe said:

    ... Accessing private properties via reflection is just fucking stupid, and should be a sackable offence.

    I'd agree because I work on a seriously over-architected pile of garbage.

    FTFY.

    Sidenote, why didn't the guy just expose public getters or setters for the values you need?  Even if ITree is an imutable interface, just create a new one (ISuperTree) with those props you need which also has to implement ITree and have Tree implement ISuperTree, which won't break any code expecting an ITree.  Also, calling the private members of a concrete implementation defeats the whole purpose of interface programming.  Actually, it defeats the purpose of OO programming altogether...



  • @stationary said:

    Screen property   71   51   52   53     73   64   65   66

    Field ID               86   58   56   77     88   57   79   78

     

     

     



  • @stationary said:

     I was wrong about none of them ever being set or read; some of them are bound to JSF properties.  The numbering is impressively random, though; one section has properties 71,51, 52, and 53;  this is followed immediately by properties 73, 64, 65, and 66.

     

    I had foolisly hoped that the numbers here were "sensibly" mapped to the insanely denormalized "field_entries" table, where four columns (one of which is just a sequence number) do the job of what should be 15-20 tables (Entity-Attribute-Value, in an application where the potential attributes are strictly defined):  if property 71 were supposed to hold the value for field_id 71, there'd at least be a twisted logic.  But for those two sections, the mapping is

    Screen property   71   51   52   53     73   64   65   66

    Field ID               86   58   56   77     88   57   79   78

    This is so simple...

    7+1 = 8; 7-1 = 6, therefore 71 = 86

    5-1+1 = 5; ((5+1) / 2) + 5 = 8, therefore 51 = 58

    Makes perfect sense...



  • @C-Octothorpe said:

    ...Sidenote, why didn't the guy just expose public getters or setters for the values you need?  Even if ITree is an imutable interface, just create a new one (ISuperTree) with those props you need which also has to implement ITree and have Tree implement ISuperTree, which won't break any code expecting an ITree.  Also, calling the private members of a concrete implementation defeats the whole purpose of interface programming.  Actually, it defeats the purpose of OO programming altogether...

    No disagreement. But, there are plenty of (stupid, invalid) reasons:

    1. System-test gets almost no respect or support from engineering (they're all nice people, but they're utterly useless when you need information). Often, I ask "where is the specification for the FooBar feature?" and the response is "In FooBarWaffles.java (implied duh)".

    2. The values I need aren't even tracked by our Tree implementation of the ITree interface. They are tracked only in the SWT object. We aren't supposed to deal directly with SWT objects, we're supposed to deal only with their wrapper objects (which are essentially chaff). Because these get exported outside our company, I have effectively zero chance of getting them fixed. It's not clear who, outside our company, uses these wrappers, but I have pity for them.

    3. This person wrote an interface for a Tree that doesn't have any concept of child/parent relationships. Why would I trust this person to be able to write ISuperTree correctly?

    Fun note: this software is involved in building software for safety-critical embedded devices used in your car. Drive safe.

    Hmm...maybe I should post this stuff in the sidebar more frequently.



  • @DemonWasp said:

    Fun note: this software is involved in building software for safety-critical embedded devices used in your car. Drive safe.
    Thanks, um, so which car manufacturer uses this software again?



  • @C-Octothorpe said:

    @dhromed said:

    :3
    Your smiley looks like boobies, and that makes me happy.

    Apparently you haven't seen real boobies in a very, very long time.

    PROTIP: The nipples go on the dangly parts, not above them.

     



  • @C-Octothorpe said:

    @DemonWasp said:

    Fun note: this software is involved in building software for safety-critical embedded devices used in your car. Drive safe.
    Thanks, um, so which car manufacturer uses this software again?

    A major one

     

    (Sorry if the picture doesn't work, my work has it blocked so i can only see the google cache)



    [mod - edited img to remove width=1/height=1 - PJH]


  • @C-Octothorpe said:

    Thanks, um, so which car manufacturer uses this software again?

    A major one.

    To give you a serious answer, "more than one of the major ones; potentially all or most of them, probably through subsidiaries and contracted-out work" (and I don't know which ones myself). The software problems I'm discussing aren't directly related (which you probably guessed, seeing as very few cars render Tree-based UI elements, let alone for safety reasons). Despite code-quality and engineering-professionalism issues, you probably aren't in any danger because of the WTFery happening here.

    That is, your chances of dying because someone was DUI or DWT are orders of magnitude higher. Your chances of dying because you didn't salt the ice on your sidewalk are higher. Your chances of dying by choking on a carrot are substantially greater.



  • @Zylon said:

    PROTIP
    HA!  Now that's funny!  :)

    For what it's worth, I do in fact know where the nipples go.  I just attributed the nipple misalignment it to a limitation of the character set used...



  • @DemonWasp said:

    @C-Octothorpe said:
    Thanks, um, so which car manufacturer uses this software again?

    A major one.

    To give you a serious answer, "more than one of the major ones; potentially all or most of them, probably through subsidiaries and contracted-out work" (and I don't know which ones myself). The software problems I'm discussing aren't directly related (which you probably guessed, seeing as very few cars render Tree-based UI elements, let alone for safety reasons). Despite code-quality and engineering-professionalism issues, you probably aren't in any danger because of the WTFery happening here.

    That is, your chances of dying because someone was DUI or DWT are orders of magnitude higher. Your chances of dying because you didn't salt the ice on your sidewalk are higher. Your chances of dying by choking on a carrot are substantially greater.

     But what about the odds of a Drunk Driver getting out of his/her car, slipping on an unsalted icy sidewalk causing then to choke to deat on a Vodka enfused carrot???



  • @C-Octothorpe said:

    I just attributed the nipple misalignment it to a limitation of the character set used...

    Oh, I figured that was just the emoticon for "perky"



  •  It's the emoticon for quirky/innocent/'tehee'.

     Alternative interpretation: ballsack with the skin part bitten by vampire.

     

    :3



  •  This is more like titties:

     

     

    (. Y .)

     

     

     



  • ⊙⊙



  • Goddamn. What the fuck.



  • @Someone You Know said:

    @Renan said:

    it breaks because all those never-assigned, never-read properties are all being used with eval().
     

    Few things have given me a greater desire to punch someone in the dick than the existence of eval().

     But how else am I going to have my variable variables in Javascript???!!!



  • @brian banana said:

     This is more like titties

    (. Y .)

     This thread is now about text boobies.

    ( · )( · )



  • VV - look, it's Madonna!



  • @brian banana said:

     This is more like titties:

     (. Y .)

     

     


     



  • Now we've done it: blakeyrat is pissed at us.


  • Discourse touched me in a no-no place

    @dtech said:

    Now we've done it: blakeyrat is pissed at us.
    Like anyone cares?



  • @dtech said:

    Now we've done it: blakeyrat is pissed at us.

    Because people read this thread, but don't read any of the other threads in the same forum?

Log in to reply