1. 32
  1.  

  2. 13

    I think the author is putting too much blame on the original developer and making too much out of their 26 years of experience. Everybody makes typos, and I’ve seen a lot of abbreviated variable names from people with a lot less than 26 years of experience.

    And judging by the variable names and the function name, it wouldn’t surprise me if the names were originally from an equation in a book, using subscripts (T<sub>tpfe</sub> and T<sub>tpre</sub>), so using those names may have been more clear at the time.

    It was a good catch, but no need to throw the original dev under the bus for making mistake.

    1. 5

      Every bug is a human mistake. It follows that every bug is preventable. Hence the popularity of “if you follow this magic rule, you’ll never have bugs like this”. Follow all the rules and your software will be perfect!

      1. 3

        no need to throw the original dev under the bus for making mistake.

        Especially when the identifiers were limited to eight characters!

        1. 2

          And judging by the variable names and the function name, it wouldn’t surprise me if the names were originally from an equation in a book, using subscripts (T<sub>tpfe</sub> and T<sub>tpre</sub>), so using those names may have been more clear at the time.

          I think that’s generally a pretty bad idea. I’ve inherited code from a control theorist where they made every variable in their 200-300 line function a maximum of 3 characters. That made it pretty difficult to decipher (what’s this theta variable and why is it not an angle?). Only after the fact, did I discover that his variable names were consistent with a paper. No one else knew he was following said paper, and he didn’t cite it in a comment.

          If you are going to do this style, at least cite the source. I would still argue that’s worse than using descriptive names because it means a reader can’t take the code in at a glance.

          1. 3

            200-300 line function

            Really big functions are more likely to fail a cyclomatic complexity anyway, so you have 180-280 problems and 3 letter variable names are just one.

          2. 1

            In a way it is fair game. It is all too common to hear in a code review that “a longer name will not make the code more readable”. Or “It has been named this way for 15 years”. Or “I am sure that this could have a btter name, but why change it now?”.

            Saying “an experience engineer made this mistake” is a bit about saying “Look, this is not a rookie mistake, that makes it even more dangerous”.

            1. 1

              Yep, I’ve had way too many bugs where I just straight out typed the wrong variable name. push() instead of pop(), ++ instead of --, and so on.

            2. 2

              The opposite extreme can lead to similar bugs: overly verbose identifiers often lead to copy-paste coding, and things like queue push and pop methods that both error when the queue is full.

              The sweet spot seems to be naming so that the most significant details stand out.

              1. 1

                I like this tidbit from the Julia Documentation

                If a function name requires multiple words, consider whether it might represent more than one concept and might be better split into pieces.

                It’s a good sanity check to try to find that middle ground.