What's a local variable? (look what Intellisense has done!)



  • So I’m perusing the code of a project at work that’s using a dynamic language, Python. One of
    the features of Python is that you can define as many instance members as you want for an object
    at run-time. You can add to self to your heart’s content.

    Somehow, and I haven’t the slightest clue how, a developer decided on a few interesting things:

    1. no modules
    2. utility functions should go in a class (like Java!)
    3. all of the functions could be static, but there’s no such thing as static methods (easily) with Python (you don’t need them)… so they’re instance methods, naturally
    4. false = 0 and true = 1 (I can only imagine this came from not realizing that it’s True with a capital “T” in Python)

    Now those are WTFs in themselves… but the biggest WTF is this:

    THERE ARE NO LOCAL VARIABLES USED. EVER.

    Everything, and I mean everything, is done with instance variables in this utility class. Symbols have been renamed to protect the horribly, horribly, guilty:

    def foo(self, bar, bat, baz, zort='Troz!', isWidget=0, wonkable=0, whatsit=','):
        ''' zonk a custom fribble to a wicket '''
        self.bar = bar
        self.bat = bat
        self.baz = baz
        self.zort = zort
        self.isWidget = isWidget
        self.wonkable = wonkable
        self.whatsit = whatsit
        self.grumbles = self.bar.bonk(self.bat)
    
    if(self.grumbles):
        if(string.find(self.grumbles, self.whatsit) != -1):
            self.things = string.split(self.grumbles, self.whatsit)
            if(self.baz not in self.things):
                self.things.append(self.baz)
        else:
            self.things = [self.grumbles]
            if(self.baz not in self.things):
                self.things.append(self.baz)
    
        self.sAttrValue = string.join(self.things, self.whatsit)
    else:
        self.sAttrValue = self.baz
    
    self.ding(self.bar, self.bat, self.sAttrValue, self.zort, self.isWidget, self.wonkable)
    



  • P.S. The quip about Intellisense is because I can only imagine the "self." pattern came from prefixing everything with "this." in C# and Java.

    Also, none of the instance variables are ever used across functions.



  • @djork said:

    false = 0 and true = 1 (I can only imagine this came from not
    realizing that it’s True with a capital “T” in Python)

    What other values would you use for them?



  • @shadowman said:

    @djork said:

    false = 0 and true = 1 (I can only imagine this came from not
    realizing that it’s True with a capital “T” in Python)

    What other values would you use for them?

    Maybe my Sarcasm Detector™ isn't working, but perhaps True and False instead?



  • Hmm, according to what you've said I reckon that's semantically equivalent to this:

    def foo(self, bonker, bat, baz, zort='Troz!', isWidget=False, wonkable=False, sep=','):
    ''' zonk a custom fribble to a wicket '''

    s = bonker.bonk(bat)

    if not s:
    s = baz
    elif baz not in s.split(sep):
    s += sep + baz

    self.ding(bonker, bat, s, zort, isWidget, wonkable)


  •  This is what happens when you write in a language without learning the language first.



  • Not to grave-dig, but I just have to add that there is a perfectly good reason that true and false are defined as 0 and 1, respectively.  The rest... eh, my issues stand.



  • @djork said:

    Not to grave-dig, but I just have to add that there is a perfectly good reason that true and false are defined as 0 and 1, respectively.  The rest... eh, my issues stand.

    ...is there any way you could explain why without giving away too many details?



  • That's not that bad. But it reminds me of something that is really, very brillant. It's one of my favorite WTFs (can't go front page though because it's not written by a professional). It's a little ruby script which fails to define constants but instead defines GLOBAL VARIABLES. Imagine that.

       module Kboard
       #--------------------------------------------------------------------------
       $RMouse_BUTTON_L = 0x01        # left mouse button
       $RMouse_BUTTON_R = 0x02        # right mouse button
       $RMouse_BUTTON_M = 0x04        # middle mouse button
       $RMouse_BUTTON_4 = 0x05        # 4th mouse button
       $RMouse_BUTTON_5 = 0x06        # 5th mouse button
       #--------------------------------------------------------------------------
       $R_Key_BACK      = 0x08        # BACKSPACE key
       $R_Key_TAB       = 0x09        # TAB key
       $R_Key_RETURN    = 0x0D        # ENTER key
       [snip]

    I noticed this while looking at the script after it crashed. Brillant!

    edit: Forgot the Link.



  • @djork said:

    P.S. The quip about Intellisense is because I can only imagine the "self." pattern came from prefixing everything with "this." in C# and Java.

    TRWTF is that Intellisense does without "this." just fine if you just summon it with Ctrl-Space. It's incredible how many people seem to miss this. It was like the first thing I learned when I started using IDEs.



  • @Sunstorm said:

    TRWTF is that Intellisense does without "this." just fine if you just summon it with Ctrl-Space. It's incredible how many people seem to miss this. It was like the first thing I learned when I started using IDEs.

    I do it just so it explicitly shows where the variable is declared. A class-level variable and a local procedure/method variable can both be referenced by name without a prefix. So, I use "this." (C#) to show that it's a class-level variable being referenced (since there isn't a prefix for locals). Of course, I could always revert back to Hungarian with everything starting with "m" (obviously "g" is out with C#). I think "this." is much better. I am still having to get used to the way of referencing a class-level "const". I used VB6 for so many years that it's just odd sometimes. But, I definitely like C# more -- no doubt about that.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.