I always struggle in abbreviating variable names. Is there any standard for abbreviating variable names?
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
The standard I use is to not abbreviate variable names unless the abbreviation is more readable than the full version (
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.
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.
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.
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:
--> could be abbreviated to
---> but abbreviating it to
Would definitely not be a good option as one would not be able to understand what the variable holds just by looking at it.
The vry rsn w dn't bbrvt s t mk sr th cd s rdbl nd mntnbl e.g.
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.
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.:
could be abbreviated to
or if you want it a short as possible,
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
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).
... 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.
... 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,
... 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:
... 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").
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.