Live data from Hacker News

Why I'll never abbreviate a variable as long as I live

beehollander.wordpress.com

31–40 of 111 posts

Re: Why I'll never abbreviate a variable as long as I live

#31

Pwd stands for: ________? Correct, you guessed it! Once an abbreviation or acronym becomes widely used it makes sense to use it as a variable name for as long as you live.

I think pwd, dir, cd and the like are obviously standard abbreviations, but that's pretty obvious that's not what I'm talking about.

Re: Why I'll never abbreviate a variable as long as I live

#32
I think the usual rule is that the size of a variable's name should be a function of the size of the scope in which it's visible: If it's a global, it should have a long, descriptive name, perhaps with_underscores or CamelCase or similar. If it's a class member, abbreviate it some. Function locals get even shorter names, and loop indices or temporary variables only used in one part of the function can be single-character.

Re: Why I'll never abbreviate a variable as long as I live

#34

"Never abbreviate a variable" is a very strong statement, surely inspiring religious wars. And maybe there are edge cases: i as a loop counter, id for an integer primary key, whatever. But this example is something else entirely; "ttpfe" is honestly the worst variable name I have every seen.

Have sufficient Hamming distance could be a better maxim!

Re: Why I'll never abbreviate a variable as long as I live

#35
I self-tested variable name lengths on my own code.

Three letters is enough to avoid most collisions. Words do not make sense yet. At four letters most words become decipherable given an appropriate encoding. At five letters a two word phrase may make sense.

I make a rough decision based on variable scope - shorter lifetime means shorter variable name, but I rarely go with just one letter as it reduces uniqueness.

If I need to use a really long phrase frequently I take a mathematician's approach and alias it to an abstract and highly unique symbol. The phrase may still exist in the addressed data structure, I just avoid it within the algorithm. Mathy code also has a tendency to encourage numbered variables, e.g. "x0, x1, x2".

Re: Why I'll never abbreviate a variable as long as I live

#37

The problem was not that the variable was abbreviated. The problem was that the abbreviated variable was so similar to another abbreviated variable that was used for a similar purpose.

I would add - there's a bit of a difference between an abbreviation that just keeps something from being ungodly verbose (20 letters instead of 50), and an abbreviation that shortens something so much that the original meaning is completely lost ("Ttpfe"). This is especially true for things in context - "time of ten percent height on the falling edge" is needlessly verbose, but in context "ten_percent_falling_edge" w…

The line was adding about 5 or 6 terms, and I think it was actually an 8-character acronym that he had. It might have been like "time from ninety percent to ten percent falling edge" or "falling edge fall time ten percent" or something. Either way, it was awesome to find it.

Re: Why I'll never abbreviate a variable as long as I live

#38
post #29
post #10

Anyone else feel a bit uncomfortable reading the level of detail in this post?

I tried to keep it as high-level as I could. What would you change?

honestly I don't have any experience working with anything classified, so your judgement is likely oodles better than mine. Great story :)

Re: Why I'll never abbreviate a variable as long as I live

#39
post #6

If the variables had been named timeOfTenPercentHeightOnTheFallingEdge and timeOfTenPercentHeightOnTheRisingEdge it probably would have still been hard to notice that they had been swapped in that one line.

Yes, but the likelihood of mistyping them would be far less. 'f' and 'r' are right next to each other. 'Falling' and 'Rising' are a bit harder to unnoticeably fat-finger.

It was probably a mental mistake. It's not particularly easy to fat-finger in that specific way.
Post reply on HN