Because it's not in the requirements and I don't want to



  • We have a team lead who is militant on coding style; in particular, naming conventions. Proper, descriptive variable and method names must be used at all times, under all circumstances.

    Along comes a project where the business analysts decided that for brevity, they would denote a bunch of variables as numbered single character names: v1, v2, ..., vn. Naturally, they did this in about 60 pages of documentation as they described all the formulas, etc.

    What does our team lead do? He builds an entire module (30+ files, hundreds of functions, etc) using the v1, ... vn notation.

    The suggestion was made to do a simple global rename of the members and accessors to something more meaningful. He was adamant about not doing it because it's not in the requirements and he simply didn't want to.

    I suggested that perhaps they could be named: v1_whatTheVariableActuallyMeans, which would prove useful to new developers while still matching the specs. I have long ago learned that with this guy, you make a suggestion once, and then let it go because he doesn't listen.

    I sat there laughing to myself as the ensuing argument between him and 5 other developers lasted for more than an hour.

    15 years until retirement and counting...

     



  • @snoofle said:

    15 years until retirement and counting...

    Hi! 44 years here! and not even graduated yet!

    I'm afraid.



  •  Obviously he's a pod person now. You're the only one who knows. You must be the vanguard for mankind before the invasion is complete. KILL YOUR TEAM LEAD.

     [Butters]

    KILL JOHN LENNIN.

    [/Butters]



  • @snoofle said:

    15 years until retirement and counting...
    For what it's worth, you could jump off a bridge tomorrow.



  • @snoofle said:

    Along comes a project where the business analysts decided that for brevity, they would denote a bunch of variables as numbered single character names: v1, v2, ..., vn. Naturally, they did this in about 60 pages of documentation as they described all the formulas, etc.
     

    Can you kill your business analysts at the same time as you kill the team lead? Or just pass on their details to me and I'll send them to the IIBA brute continuous improvement squad.

    Business analysts should be writing for clarity, not brevity.Yes, we sometimes use too many words and don't always successfully deal with all the other fun problems that come from trying to bridge between the precision of program code and the flexibility of ideas. And yes, describing requirements using formulas can be a valid way of bridging that gap. But messing it up with a bunch of obscure short variable names is just wrong - unclear and error-prone - a WTF on so many levels.

    But yes, your team leader is a clear source of WTFery too. One wonders:

    • If one of the BAs had reason punched into them and did a search-and-replace on the variable names, would your team leader then insist that the software has to be edited, recompiled and tested?
    • If the requirements were written purely in English, would your team lead see that as requirement to only program in English (or, the next worse thing, COBOL)? (Hate to think what your team leader would do if the requirements were in French, Korean, or Russian then!)
    • If this is your team leader's approach to coding from requirements, could he be made redundant and replaced by a Word VBA macro?

     



  • If you write an eclipse plugin that allows personal variable renaming (presents me with another name, saves and loads the original), we'll all love you forever.



  • @snoofle said:

    ... bunch of variables as numbered single character names: v1, v2, ..., vn.
     

    Uhhh, isn't that two characters?



  • @snoofle said:

    We have a team lead who is militant on coding style; in particular, naming conventions.

    ...

    What does our team lead do? He builds an entire module (30+ files, hundreds of functions, etc) using the v1, ... vn notation.

    Something about this story strikes me as a little odd, or inconsistent. Can we skip forward to the part where you explain why all naming conventions your lead lived by suddenly went out the window?



  • @badcaseofspace said:

    Can we skip forward to the part where you explain why all naming conventions your lead lived by suddenly went out the window?

    He sometimes does a complete about-face - WE have to abide by naming conventions, but when HE is coding, they don't necessarily apply.

    Also, somewhere in between, he was promoted to team-lead, which seems to have had a magnifying effect on things like this.

     



  • "Name all the variables v1, v2, etc" is a naming convention, just not a very good one.



  • @snoofle said:

    WE have to abide by naming conventions, but when HE is coding, they don't necessarily apply.

    We have a guy like that at work.  Fortunately, he's been promoted to a position where he mostly does design and pseudo-code, so this isn't an issue as much.  (And it is a good thing, because he's a really smart guy - he apparently just can't be bothered to spend the additional time to follow his own standards all of the time.  Fortunately, he's also sane enough that if someone else wants to clean up his variable names and formatting, he's happy to let them.)



  • @snoofle said:

    ... a bunch of variables as numbered single character names: v1, v2, ..., vn.

    Ugh. We used to have a developer who routinely did this (despite it contradicting our established, documented style) in the name of "rapid application development".


  • 🚽 Regular

    @mars-red said:

    Ugh. We used to have a developer who routinely did this (despite it contradicting our established, documented style) in the name of "rapid application development".
     

    That's his way of saying, "I never learned how to touch type and I only use my index fingers to code."



  • @RHuckster said:

    That's his way of saying, "I never learned how to touch type and I only use my index fingers to code."

    Haha, needless to say he never left a peer-code-review session unscathed and was eventually "let go". One of my favorite things about the company I work for is that they have no problem firing someone if they deserve it. I've worked so many places that just put up with "dead weight" (or in some cases, even worse than dead weight), leaving their co-workers to cope with the fallout. This is quite refreshing, and it's the way things should work (and as an engineer, it really tickles my engineering bone when stuff works the way it should).



  • @snoofle said:

    We have a team lead who is militant on coding style; in particular, naming conventions. Proper, descriptive variable and method names must be used at all times, under all circumstances.

    There are very few teams that have so few big problems that they have the luxury of concentrating on such minutia.  Any time someone gets militant about naming conventions, I immediately know that the correct course of action is the opposite of whatever this moron says.



  • @Jaime said:

    @snoofle said:

    We have a team lead who is militant on coding style; in particular, naming conventions. Proper, descriptive variable and method names must be used at all times, under all circumstances.

    There are very few teams that have so few big problems that they have the luxury of concentrating on such minutia.

    I'd like to agree with that.  Maybe it is true.

    However, having been on a team where the code formatting and typical naming conventions went so far the other way that they were the cause of 90% of the department's really big problems1, I'm not sure this is true as frequently as you think it is.

    1 As determined by the fact that when the team was required to start formatting their code and naming their variables more reasonably, that's the percentage of problems that simply disappeared.  Admittedly, most of them were explicitly addressed, but before that change, every time one bug was fixed, another one would show up.



  •  We tend to bitchslap eachother for bad code, and as a result we maintain eachother's projects fairly easily, despite having only a superficial coding standard.

    Document quality can never outdo team quality. :)



  • @tgape said:

    @Jaime said:
    @snoofle said:

    We have a team lead who is militant on coding style; in particular, naming conventions. Proper, descriptive variable and method names must be used at all times, under all circumstances.

    There are very few teams that have so few big problems that they have the luxury of concentrating on such minutia.

    I'd like to agree with that.  Maybe it is true.

    However, having been on a team where the code formatting and typical naming conventions went so far the other way that they were the cause of 90% of the department's really big problems1, I'm not sure this is true as frequently as you think it is.

    1 As determined by the fact that when the team was required to start formatting their code and naming their variables more reasonably, that's the percentage of problems that simply disappeared.  Admittedly, most of them were explicitly addressed, but before that change, every time one bug was fixed, another one would show up.

    I find it hard to believe that there exists a group of people who can't figure out how to name a variable, but don't suffer from a compulsion to abuse global variables, massive layer confusion, a predisposition to program by side-effect, or the complete inability to grasp the concept of object oriented programming.  My nightmares are generally caused by hardcoded server names and code that can only be tested by replicating an entire ten server system in the test environment and performing a five hour process just to run a report - somehow the code on the ten servers made it into production without ever passing through the test environment.

    However, I have reformatted code and found that the source of a difficult bug was made obvious as soon as you can see the code nested properly.  But, this has nothing to do with variable naming.



  • @dhromed said:

     We tend to bitchslap eachother for bad code, and as a result we maintain eachother's projects fairly easily, despite having only a superficial coding standard.
    Going on my table alias rant again.  I hate motherfuckers that think that a, b, c, x, y, z are acceptable table aliases.  

    I have confronted a coworker about this twice this week.  He said "I only do it to bug you."

    Jerk.



  • @belgariontheking said:

    I hate motherfuckers that think that a, b, c, x, y, z are acceptable table aliases.  
     

    I think they're perfectly acceptable for "Assistants", "Books", "Customers", etc, but as you said earlier, when "a is my main fact table, b is the date table, and c thru f are copies of the lookup table", that is of course bullshit and extremely annoying.

    I have my own horrorstory with short variable names.

    I worked with a company that also produced a Income Tax application; they asked me to maintain that. In the first version, the original developer has used the numbering of the questions for variable names; so for instance v_2f would refer to question 2f. Doesn't sound too bad? What he hadn't realized, is that these questions change a bit from year to year, so 2f might next year be question 2g. He solved that by just shuffling around the controls on the form, and keeping the names. After a couple years, many changes and a second developer, this meant that by now, 2f might in fact be 4a. Or 2f. Or 13z. Or null. There was absolutely no way to tell.

    The main calculation was a totally uncommented messy function of 1000+ lines (no whitespace), all referring to these v_4g = v_2f + v_13h (or similar), so I took a look, closed the project, took a couple aspirins and a huge whiskey and told my boss to hire the last known developer back to fix it (the guy had left to go free lance).

    The happy ending of this story is that he did in fact do that and didn't bother me with that crap again :-)



  • @b_redeker said:

    ...The main calculation was a totally uncommented messy function of 1000+ lines (no whitespace), all referring to these v_4g = v_2f + v_13h (or similar),

    I think I know that guy! (I'm sure everyone here could say the same thing, actually) :)



  • @belgariontheking said:

    Going on my table alias rant again.  I hate motherfuckers that think that a, b, c, x, y, z are acceptable table aliases.  

    I have confronted a coworker about this twice this week.  He said "I only do it to bug you."

    Jerk.

    There is only one valid way to end this:

    Him: Dude, why'd you butcher my wife, kids and dog?
    You: I only did it to bug you.
    

Log in to reply