How to abbreviate variable names [closed]

Question

I always struggle in abbreviating variable names. Is there any standard for abbreviating variable names?

Answer 1

The standard I use is to not abbreviate variable names unless the abbreviation is more readable than the full version (i for iteration indices, for instance). We name things so that we can communicate. Abbreviating variable names typically just lessens their ability to communicate.

Answer 2

I'm not a C# programmer, so I can't give you much advice about C# conventions. But I do have some thoughts about abbreviations.

As I've gotten older and more experienced I've found myself abbreviating less and less. I'll admit that I was not a very good typist when I started programming. I've gotten better at that since then ;). I will abbreviate freely for variables that have very limited scope, such that I can see their entire lifetime on one screen. But other than that I prefer not to if I can avoid it- I never abbreviate to save typing.

I do still try to keep my lines under 80 chars. I'm not sure if that makes sense these days, but it is an old habit. So I will abbreviate if a variable name is otherwise going to be very long. But before I do that I will try to find a more succinct name that is equally clear- all else equal shorter is better (speaking of the expanded form.)

Where you do abbreviate it is most important, I think, that you always abbreviate the same way in a given codebase, and across related codebases. Your first instinct is likely the one to go with, as it will be easiest for you to remember, but it can be worth checking with other people on the same project. These days I work mainly with one other programmer, in an open office full of non-programmers. They think we are insane, because we often have detailed discussions about things like how to consistently abbreviate related variable names, or consistently order parameters in function calls, etc. But naming matters, even for two people. On larger teams it becomes even more important. One thing I am pretty religious about is fixing inconsistencies in things like this as soon as I spot them.

EDIT: some abbreviations are good though, I think. In my current job a lot of the code I write has to do with evaluating splines, and other parametric functions, at certain parameter values. Our codebase is in fact inconsistent in this regard. I know that u is used in some places and param (an abbreviation itself) is used in others. U is a generally understood abbreviation for parameter in this domain so I think we ought to go through and make this consistent. I would be fine with any of u, param, or parameter. We use them so much that there is unlikely to be any confusion, as long as we use just one. But I would prefer u.

It's worse than that though- we actually have several types of parameter. And we have more than one name for some of them- uggh.

The reason this got inconsistent is textbook. It turned out that we had to map between six parameter spaces- the reasons are complicated, but basically we had to have parameters that corresponded to parameter space, normalized parameter space, arc length space, normalized arc-length space, piecewise space, and normalized piecewise space. We didn't realize, at first, that we would have to map back and forth between all these spaces. And we were inconsistent in how we named parameters that describe points in those spaces.

This happens sometimes- your app grows up, and you do some inconsistent things while growing it. The important thing is that you recognize that you have gotten messy and go in and fix it before the messiness infects everything else and you wind up with a pile of rubble.

Answer 3

The vry rsn w dn't bbrvt s t mk sr th cd s rdbl nd mntnbl e.g.

int accountBalanceInSavings;

// could be abbreviated to
int accBalInSaving;

Note that two of the four words are shortened (account->acc and Balance->Bal), but the other two are not. What rule is applied here -abbreviate the first 2 words, it's not "words over 6 letters", because 2 7 letter ones were and one wasn't.

So could/should it be accBalInSav, yuk yuk yuk...

My experience as programmers get older and wiser, they abbreviate less and less. By my age, we are probably trying to make up for the sins of our youth though...

Keep in mind code is written once (ok, many a few more then once) and read thousands of times.

Answer 4

I do not believe there are any official or common rules for abbreviations. Usually a system of abbreviations is developed by each individual and within each individual project. There can be certain rules for a company's source code style policy but that as well will vary on the company basis.

On a side note, why abbreviate at all? That will result in only you understanding what the abbreviations mean. Use full and descriptive names for variables. That will lead to self-documenting code.

Answer 5

There is a similar question about single char names, Using single characters for variable names in loops/exceptions.

My answer then as now is to keep them short where the scope is small. For example, a parameter of a short function is more readable if it's short and takes less space. A class wide variable should be very descriptive.

Steve McConnell's classic book Code Complete is great for stuff like this.

Answer 6

If in doubt, spell it out.

The point of a variable name is so that the meaning of the code is clearer. Unless the abbreviation is very obvious one, then you may as well just use the smallest one possible. Variable names and function names are typically the only bits of human language in the code and so act both as 'landmarks' for the human eye to find relevant portions of code (or, in a large codebase, tools like grep or ack) and also as clues for comprehension.

When the next person comes to read your code, they will thank you for it. That person could well be you in a year's time. I have a lot of code I regret abbreviating, so nowadays I try to avoid it.

It's ok to abbreviate when...

... When the abbreviated form is used in spoken or written English by more than just the people working on your project (many dictionaries give this sort of information next to the term they define).

var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation

... When the abbreviation refers unambiguously to a single concept and would be instantly recognised by someone who is not familiar with the codebase. Even then a comment or piece of documentation helps.

var auth = user.auth;
if (auth) // If the user is authenticated?
          // If the user is authorised to do something?
          // If the authentication function exists for that user group?
          // If some setting called auth is turned on for that user?
          // If the user is the author of the document in question?
          // If the user has some authority?

var attrNames = retrieveAttrs();
if (attrNames)  // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!

const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name

... When the variable name exists only in a single scope or small function, and you do not expect the user to derive meaning from the name, use a single character. In such cases, i and j are common.

foreach $i (1..10) { say $announcement->[$i] }

... When writing an interface (i.e. not a variable name, so outside of the scope of the question, mentioned only because variable names and interfaces which set them often use the same vocabulary) in which case other rules may apply, for instance:

some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done"    # if you can spare -m

... When your codebase needs to refer to the same concept many times in the same project and when the abbreviation can be defined in a style guide for that project, and when it is unambiguous. If your project is not big enough for a style guide then it's not big enough for it to be worth it.

I'm not going to provide a code example to this one because by definition it only works in a large project, but see also the next item:

... When working on an established project which has had multiple contributors and a style guide which mandates abbreviations. In which case, abbreviate only as per the style guide, but look out for problems and be prepared to annotate with comments (like "this is a list of attribute names as strings").

Types should end in “_t” ; Raw struct definitions in “_struct”

- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt

One final thought: if you still have unacceptably long variable names (e.g. composed of four or more semantic units like totalAfterTaxInLocalCurrency), it could be a symptom that your code is trying to do too much in a single scope and its functions need to be refactored out or your variables might be more logically managed in a single object.

Answer 7

The reason we abbreviate variables is to stop typing large variables, but at the same hand the abbreviated variable should be explicit enough that you can understand what it hold rather than going back to where it was declared or instantiated first. So for example:

int accountBalanceInSavings

--> could be abbreviated to

int accBalInSaving

---> but abbreviating it to

int accBal

Would definitely not be a good option as one would not be able to understand what the variable holds just by looking at it.

Answer 8

You shouldn't abbreviate stuff for the sake of abbreviating stuff, you should do it for your/others convenience, but if you want to then a general rule that I have for abbreviation is if a word is more than four or five letters long then I'll shorten it to the first three significant letters of that word, e.g.:

int damagePerSecond;

could be abbreviated to

int dmgPerSec;

or if you want it a short as possible,

int dps;