Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
Is this a duplicate of stackoverflow.com/questions/4358840/…? –  delnan Apr 29 '11 at 22:44
Take the hint. If it's difficult, then stop doing it. –  S.Lott Apr 29 '11 at 23:27
@S. Lott, but ... getting my PhD in biochmepsychophysiogeocraniuminformatics degrees was also difficult but I did not stop. I am glad that I did not. –  Job Apr 30 '11 at 3:35
Working with abbreviated identifiers in code you did not write causes brain damage. –  Rick Sladkey Apr 30 '11 at 4:19
rigidly following rules is either a cause of or a sign of brain damage. Either way, the important thing is judgment. –  T Duncan Smith Apr 30 '11 at 6:58

7 Answers 7

up vote 44 down vote accepted

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.

share|improve this answer
+1: Don't abbreviate. –  S.Lott Apr 29 '11 at 23:26
Not sure I entirely agree. I don't abbreviate much, but I think that abbreviating in some cases is a good idea. I would find long variable names in a short local scope very annoying, actually. I write lots of functions where "p" refers to a point in 3-space. I think that that is as clear as "thePoint," and easier to read, if the function is meant to operate on a point in some fashion. –  T Duncan Smith Apr 30 '11 at 5:33
As I said, I prefer full names "unless the abbreviation is more readable". It sounds like we actually agree. –  Rein Henrichs Apr 30 '11 at 7:25
@Duncan, maybe that is clear to you, but not everybody would immediately see the correlation between the abbreviation and what you actually mean. I think all variables should be fully descriptive, unless you can make them immediately understandable to all other users. As Rein stated using 'i' in a loop is one such scenario where I believe it to be acceptable. –  Darren Young May 5 '11 at 9:56
I almost agree. I would say, don't abbreviate, unless the abbreviation is so common, that there is no doubt as to what is stands for. A good example is System.IO. Common could also be common just in the company that you work in. That would of course mean that new employees would not know exactly what it means. But being part of the company would mean that sooner or later they would learn the company lingo. –  Pete Jun 9 '12 at 13:03

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.

share|improve this answer
Interesting, assuming you use visual studio, I wouldn't abbreviate parameters because they'd come up as soon as you type "myfunc(" and you don't want it to say double createBox(string tb, int cir, double pmj), just a thought to add –  Mark Lalor Apr 29 '11 at 23:00
I mainly use emacs. I'm a bit of a dinosaur I suppose, but I also have to work with a couple of languages (at the same time, in the same code) across a number of platforms. I do sometimes abbreviate parameters if the abbreviation is obvious (and consistent,) because I try for short enough functions that I can see them all on one page, but I often don't, because I do my best to keep function signatures short anyway. The most important thing is consistency though- if "the same" parameter (conceptually) is abbreviated in one place it should always be like that. –  T Duncan Smith Apr 29 '11 at 23:04
Anyway, the main point here, IMHO, isn't even to let you automatically type the right thing without looking it up (though that's a bonus.) The main point is to reduce cognitive burden when reading the code later. It's a cliche, but you tend to read even your own code a lot more times than you write it. If the essential ideas are essentially hard you want to eliminate as much inessential cognitive burden as you can. Consistency helps here. It's an impossible ideal, but ideal code should only contain irreducible difficulty. –  T Duncan Smith Apr 29 '11 at 23:14

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 shortend (account->acc and Balance->Bal), but the other two are not. What rule is applied here -abbrivate 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 exprience as 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
I'd mistake accBalInSaving for accumulated Bal In Savings –  KajMagnus Oct 10 '12 at 4:33

If you want to communicate, you mustn't abbreviate.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.