Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

beehollander.wordpress.com

Post reply on HN
Print view View original

71–80 of 111 posts

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

#71

Post by santaclaus »

stevep98 wrote: post #30

I was recently implementing a geometry algorithm which I looked up on quora. It was described using typical vector notation, using r,s . t,u. Since I referenced the algorithm in the comments, I decided to use these same variable names in my code. I think this is the right choice, but my code reviewer didn't. But he didn't click on the quora link. Why is okay for mathemeticians to abbreviate things but programmers? Is…

I find that as a piece of code skews more math- and geometric- centric, the variable names skew more towards math-like brevity as well. To some degree this is due to historical technical limitations (LAPACK and Fortran being one extreme -- dgbsv anyone?), but I see a ton of contemporary production code with one letter variable names. R is a rotation, n is a normal, p is momentum, whatever. I think a lot of the historical notation conventions carry over to code, and most peeps working in the domain day to day are down with whatever baggage is brought along. This is fine until you try to read francophone code... try reading a French a thesis and you'll find that they spur all conventions that the rest of the world has agreed upon :).

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

#72

Post by adrianratnapala »

One thing I often see elided in these naming wars is scope: am I the only person who gives longer names to globally visible things than to locals?

For example:

    size_t *find_foo(const char *source_text)
    {
        const char *src = source_text;
        for(; src != 'f'; src++)
           ... do stuff
        ... do more stuff

        return src - source_text;
    }
Now the meaning of "source_text" would not be evident, except for the name. But just glancing at the usage shows that "src" is clearly a working cursor into the source text.

But if I called it "working_cursor" would that really explain anything to the reader? If anything, giving a detailed name risks misleading readers in much the same way as stale comments can mislead.

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

#73

Post by component »

mmaunder wrote: post #12

When hiring we ask for sample code from developers written specifically for the job application. We place a really high premium on readability. Occasionally we'll get code from devs that is very concise - not just abbreviated variable names, but complex long statements using ternary etc. I'll usually ask them to resubmit code and really focus on readability and it turns out fine. But I think there might be a misconce…

Whenever we interview a candidate, the one thing we give high premium on is structure, the rest come next.

bad variable names, long complex code...can easily be adjusted. If the candidate doesn't have a good understanding of how to structure a code (what goes where, for what purpose, separation on concern...), it'll take much more effort to teach that candidate than to teach the bad variable namer.

Properly structured code naturally leads to a better performing software, even if/when a bug arises it'll be easier to spot / test.

All that being said, if a coder names a variables, 'a', 'aa', 'aaa', 'aaaa' that's a serious red flag.

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

#74

Post by knocte »

mmaunder wrote: post #12

When hiring we ask for sample code from developers written specifically for the job application. We place a really high premium on readability. Occasionally we'll get code from devs that is very concise - not just abbreviated variable names, but complex long statements using ternary etc. I'll usually ask them to resubmit code and really focus on readability and it turns out fine. But I think there might be a misconce…

I'm sorry, how can verbose code impact performance???? Please elaborate.

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

#75

Post by other_herbert »

benkuykendall wrote: post #8

"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.

I've seen where the typing skill of the person implementing something will affect how verbose they are...

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

#76

Post by buzzybee »

rileymat2 wrote: post #47
buzzybee wrote: post #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…

Did you self test on code from years ago or was it all fresh in your mind?

I had approximately a month between when I wrote it and reread it. While it was serviceable in short-term memory, comprehension suffered noticeably in the long term with four-letter or less names.

At the time I did this I was pursuing Arthur Whitney's extremely terse style to see what advantages and disadvantages it brings. My main modification was to add a full description comment inlined into the declaration of every variable, a practice which I have mostly kept up with even after the experiment ended, e.g.:

    var tz : String; /* time zone */
This meant that I was not testing on whether I could reconstruct the entire meaning in my head, just whether it made code flow better to use very short names. My discovery was that it does help, up to a point, because you can always create original short names that differentiate better than long abbreviations:

    result = ttpfe + ttpre;
vs.

    result = q + k;
Any time you copy-paste-modify, you create a risk of error. Including the whole phrase slows down your reading and brings diminishing returns on comprehension as it puts friction on actually working with the variable. With the highly differentiated "q" and "k", error has a lower likelihood of slipping in than the abbreviation because you've minimized the amount of noise in the data - it "chunks" better and you can read the whole algorithm more fluidly. The only problem with using such short names is the issue of reconstruction, which is why I opt for aliasing a long name if I need to work with it frequently, even if it means extra boilerplate to make a local variable. Abbreviation is the worst of both worlds and so I try not to do so much of it.

Given the original 8-character constraint of OP I might have tried something along the lines of:

"edge_t0" "fall0" "ef"

Because there is no way to convey the entire phrase, I see it as preferable to focus on a key aspect, expand that word, and push everything else into more symbolic content, especially numbers. Programmers are already trained to look carefully for uses of 0 vs. 1 in our code. That doesn't mean it's my go-to for an abstract symbol, but it works better than a bad abbreviation.

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

#77

Post by saosebastiao »

pshc wrote: post #25
saghm wrote: post #5

I definitely prefer more verbose names to abbreviated ones, but I'm not sure that never abbreviating a variable name is the right way to go either. Surely there's a middle ground between `Ttpfe` and `timeOfTenPercentHeightOnTheFallingEdge`?

tl;dr: use newtypes! I like using static types to avoid these sorts of problems. Modern languages like Swift, Rust and Haskell let you make zero-overhead type wrappers around other types. So here they could have defined `newtype RisingEdge(Float)` and `newtype FallingEdge(Float)`, and then use those types in the function parameters as appropriate. Helps shorten function names to boot!

This is incredibly powerful when done correctly. Ive come across a few similar features in F# that I wish were available in other languages, such as units of measure (F#) and active patterns.

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

#78

Post by Roboprog »

component wrote: post #73
mmaunder wrote: post #12

When hiring we ask for sample code from developers written specifically for the job application. We place a really high premium on readability. Occasionally we'll get code from devs that is very concise - not just abbreviated variable names, but complex long statements using ternary etc. I'll usually ask them to resubmit code and really focus on readability and it turns out fine. But I think there might be a misconce…

Whenever we interview a candidate, the one thing we give high premium on is structure, the rest come next. bad variable names, long complex code...can easily be adjusted . If the candidate doesn't have a good understanding of how to structure a code (what goes where, for what purpose, separation on concern...), it'll take much more effort to teach that candidate than to teach the bad variable namer. Properly structur…

"I ran the code through minify, but it's bigger now?!?"

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

#79

Post by Roboprog »

pshc wrote: post #25
saghm wrote: post #5

I definitely prefer more verbose names to abbreviated ones, but I'm not sure that never abbreviating a variable name is the right way to go either. Surely there's a middle ground between `Ttpfe` and `timeOfTenPercentHeightOnTheFallingEdge`?

tl;dr: use newtypes! I like using static types to avoid these sorts of problems. Modern languages like Swift, Rust and Haskell let you make zero-overhead type wrappers around other types. So here they could have defined `newtype RisingEdge(Float)` and `newtype FallingEdge(Float)`, and then use those types in the function parameters as appropriate. Helps shorten function names to boot!

I miss Pascal "type" block definitions (or C typedefs, at least) when I have to work with too many Java generics.

I know, [Turbo] Pascal (etc) never had generics. But if they had, you would have been able to make a type with a generic expression, rather than a constantly repeated inline monstrosity of an expression.

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

#80

Post by ScottBurson »

cbd1984 wrote: post #20
benkuykendall wrote: post #8

"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.

Historically, i wasn't even an abbreviation: It was the first variable name which would be assumed to be integer by FORTRAN compilers which implicitly assigned types to variables based on name. The choice was probably further influenced by longstanding mathematical tradition, which uses i and j as indices. (You could declare types and the compiler would respect it, leading to the old truism "GOD is REAL, unless decla…

I think the weirdest thing old Fortran did was to let you pass a constant by reference to a subroutine, which could therefore change its value.
Post reply on HN