Typing is easy. Thinking is hard!
Why I'll never abbreviate a variable as long as I live
61–70 of 111 posts
Re: Why I'll never abbreviate a variable as long as I live
#62"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.
Ah, good ol' TransactionTemplatePayloadFactoryExtension.
I've just started using Spring in my internship now and some of the class names in our code are pretty hysterical.
Re: Why I'll never abbreviate a variable as long as I live
#63Earlier quoted context omitted.
sure but if the variable was not abbreviated the chance of collision would have been less.
Even with a 200 character variable name, the chance of collision is 100% if it was auto-completed or copy-pasted.
At a minimum, readable variables would have simplified identifying the issue after it was introduced.
Re: Why I'll never abbreviate a variable as long as I live
#64May I recommend checking out Rob Pike's document for a counter-point http://doc.cat-v.org/bell_labs/pikestyle
I think that his variable names section is utterly ridiculous, but it's a relevant read from a relatively prolific person, so worth sharing.
Re: Why I'll never abbreviate a variable as long as I live
#65I 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…
In math, notations are designed to make statements about the problem domain concise. Once you pass a certain degree of concision, longer names impede readability rather than enhancing it. That is because the ability to take in an entire complex expression or subexpression at a glance tells you things—and lets you see patterns—that wouldn't be as apparent if longer names were used. Programmers in the APL tradition understand this, but most programmers do not. (Many refuse to believe it's possible when they hear about it!)
In software, programmers have grown accustomed to a notion of readability that derives from large, complicated codebases where unless you have constantly repeated reminders of what is going on at the lowest levels (i.e. long descriptive names) there is no hope of understanding the program. In such a system, long descriptive names are the breadcrumbs without which you would be lost in the forest. But that is not true of all software; rather, it's an artifact of the irregularity and complexity of most large systems. It's far less true of concise programs that are regular and well-defined in their macro structure.
In the latter kind of system, there's a different tradeoff: macro-readability (the ability to take in complex expressions or subprograms at a glance) becomes possible, and it turns out to be more valuable than micro-readability (spelling out everything at the lowest levels with long names).
It also turns out that consistent naming conventions give you back most of what you lose by trading away micro-readability, and consistent naming conventions are possible in small, dense codebases. That of course is also how math is written: without consistent naming conventions and symmetries carefully chosen and enforced, mathematical writing would be less intelligible.
Edit: The fact that readability without descriptive names is widely thought to be impossible is probably because of how little progress we've made so far in developing good notations, and tools for developing good notations, in software. This may not be so hard to understand: it took many centuries to develop the standard mathematical notations and good ways of inventing new ones to suit new problems. Mathematics is the most advanced culture we have in this respect, and in computing we're arguably still just beginning to retrace those steps. If we wrote math the way we write software, mathematics as we know it wouldn't be possible.
Edit 2: The best thing on this is Whitehead's astonishingly sophisticated 1911 piece on the importance of good notation: http://introtologic.info/AboutLogicsite/whitehead%20Good%20N.... If you read it and translate what he's saying to programming, you can glimpse a form of software that would make what people today call "readable code" seem as primitive as mathematics before the advent of decimal numbers seems to us. The descriptive names that people today consider necessary for good code are examples of what Whitehead calls "operations of thought"—laborious mental operations that consume too much of our limited brainpower—which he contrasts to good notations that "relieve the brain of unnecessary work".
Applying Whitehead's argument to software suggests that we'll need to let go of descriptive names at the lowest levels in order to write more powerful programs than we can write today. But that doesn't mean writing software like we do now, only without descriptive names; it means developing better notations that let us do without them. Such a breakthrough will probably come from some weird margin, not from mainstream work in software, for the same reason that commerce done in Roman numerals didn't produce decimal numbers.
Re: Why I'll never abbreviate a variable as long as I live
#66I would suggest that the need for Englishy variable names is due to a weakness in programming languages and possibly the programming model itself. Why should a set of legitimate values for a computation benefit from how you refer to that set? Can that variable take on undesired values? Do you rely on that name and its comprehensibility to distinguish good from bad values? I sometimes find it hard to believe we still program this way.
Re: Why I'll never abbreviate a variable as long as I live
#67I 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…
Math is verb-oriented, so you shorten the variable names to make the structure clear. Most programming is noun oriented, so you clarify variable names at the expense of taking attention away from structure.
Math does name its nouns, but those tend to be structures rather than variables (groups, rings, fields etc.)
Re: Why I'll never abbreviate a variable as long as I live
#68If 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.
I think the catch is that the 'f' and 'r' keys are right next to each-other, so if you accidentally type one instead of the other then you'd get the other variable by mistake. That said, you raise a fair point - we don't know how this bug got there. If it was a simple typo like above then the verbose names would have prevented it. If it was a logic error by the programmer (For whatever reason), then you're right that…
Fat-finger is only one kind of error -- and one far less common than the good-ole brain-spasm which can easily replace "Falling" with "Rising".
The ability to read the code an find see the error is more important. And one that score even though ttpfe is a terrilbe name "timeOfTenPercentHeightOnTheFallingEdge", is even worse.
Re: Why I'll never abbreviate a variable as long as I live
#69> The term was supposed to be “Ttpfe”, but he had mistakenly called it “Ttpre”,
The same cognitive mistake could have happened with it spelled out. Two concepts closely related can easily be confused.
Re: Why I'll never abbreviate a variable as long as I live
#70I would suggest that the need for Englishy variable names is due to a weakness in programming languages and possibly the programming model itself. Why should a set of legitimate values for a computation benefit from how you refer to that set? Can that variable take on undesired values? Do you rely on that name and its comprehensibility to distinguish good from bad values? I sometimes find it hard to believe we still…
We don't have to still program this way - you can write code with very strict types, with machine-checked proofs that it works correctly, etc, etc. We don't do this very often because it turns out this level of rigor is incredibly time-intensive.