Why do C programmers use short variable names (e.g., ‘sz’ instead of size) when it makes code harder to read?

It seems like short variable names in older language is a habit that started in a different time and has magically transported itself forward.

However, as strange as that habit is…

I think long variable names are worse.

Here’s the problem. You are confusing reading with understanding and in fact shorter variable names can sometimes make code easier to read or understand.

The problem with descriptive variable names is that programmers spend a bunch of time twiddling their thumbs trying to come up with a good variable name. And then when they do some other programmer shows up in a pull request and decides that descriptive name isn’t descriptive enough.

And so they start calling each other names and hurting each other’s feelings over what is the “correct” way to name variables.

That is a stupid and useless argument 90% of the time because….

VARIABLE NAMES DON’T REALLY MATTER!

Variable names are arbitrary. They are made up. They in theory could be literally anything. They are symbolic representations of what might be stored.

Yes, they are useful, but they could also be LITERALLY ANYTHING and the program would run the exact same way. That is how refactoring works right? That’s how minifcation works right? That’s how compilers are able to turn your silly variable names into useful code.

Everything outside of humans in the world of computing thinks that variable names are basically symbolic placeholders and they contain no real meaning.

So why do we overload variable names with meaning?

Because in real life, words have meaning. So when we use those words in code, we re-use their meaning. Even if it doesn’t make sense!

For example, in programming there are two common and reasonable ways to do error handling. You can return errors or throw exceptions. Programmers like to use errors instead of exceptions because “exceptions should only be used when something exceptional happens”.

That kind of nonsense logic is insane. If you flipped the words around the logic looks truly absurd. “errors should only be used when something error(al) happens” or if they were called bats and balls instead of errors and exceptions we would never say “bats should only be used when something batty happens”.

And yet, programmers argue about that kind of stuff on the internet for hours and days. In fact, my guess is I’ll get some angry comments about why naming variables is so important and why errors are better than exceptions and why the correct color of the bike shed is in fact purple…

Which is the entire point.

Programs are sets of instructions that a computer runs and we make sense of in our minds. When you code, you are taking some text and re-assembling the meaning and re-running the program in your brain. The translation between a computer, some text, and how we represent that in our brain is completely arbitrary.

And because it’s arbitrary, I believe that instead of arguing about variable name length or what color the bike shed should be, we should focus our attention on how we are communicating with each other and the machine. Variable names are such a tiny, tiny part of that.

It’s like, we are arguing over whether Luke Skywalker should be Luke S., Luke, he, him, jedi #5, Skywalker, Young Skywalker, or maybe “That punk kid who blew up the Deathstar”.

It really doesn’t make much difference as long as you pick one and are consistent with its usage. People are smart enough to figure it out.

-Brian

P.S. I write about code and career issues elsewhere too…

This one is controversial in my mind, although many programmers may disagree with me.

I think *long* names are hard to read. The brain has to work harder to parse them. However, they do (in most contexts) make it easier to *understand*. As one who has had to program in Cobol, I can assure you that wordiness and long names are not an unmixed blessing, whatever the conventional wisdom says.

Mathematicians know the benefits of conciseness, but programmers seem to be a bit behind in their understanding. Long names make lines of code hard to understand and hard to parse, and it only gets worse because most programmers (following currently accepted style) do not line code up vertically in many places where it would be beneficial. The brain likes to recognize things as a group, not as a linear sequence.

So *short* names *can* be beneficial. But they can also impede understanding if they become cryptic. I think there has to be a balance. A name should be as short as possible while making its meaning and/or purpose clear. This is, of course, a subjective measure, but with effort a team can use names the all team members can quickly comprehend.

One answer suggested the length of a name should depend on its scope. That is not a bad rule of thumb, but I would insist that short names are always better than long ones if their use and/or meaning is clear.

Programming, after all, is a means of communication. What is being communicated is algorithms and data structures. The style that communicates *best* is the best style.

It should also be noted that *nothing* prevents *long* names from being cryptic. If anyone doubts this, they should be forced to read legacy Cobol code. What matters is communication.

C is one of the oldest languages (there were definitely others before it but it’s the one that took off). In the early days of computers every character was another byte of storage that was extremely costly. In 1967 1 MB of storage was about $7,500,000 in 2018 dollars ($1,000,000 1967 dollars). Or about $7.50/byte. so if you use size vs sz you spent an extra $15 every time you used the variable. Also, ram was limited, Bill Gates was mythically credited for saying that since no one would ever need 64K they’d make DOS able to handle 640K systems. So if you had 100 variables in your system and used them 10 times in your program you have 1k per character that you could save to mSubmitake the text fit in your memory space while developing.

So older programmers keep the same habits, and newer programmers pick up the habit when working with older code. Most new developers aren’t given new programs to develop. Instead they wind up working with legacy code and pick up habits (good and bad) from that older code.

CW@50: Data storage goes from $1M to 2 cents per gigabyte (+video)

Some of this is old school tradition.

In days of yore before editors offered identifier completion and people were editing on a terminal with a fixed width of 80 characters (or even a teletype with say 132) there’s an incentive to not take up too much space with long names.

C is about 50 years old now and these fancy “Graphical User Interfaces” you speak of with their “Scroll bars” (whatever that is!) weren’t even imagined when some of these conventions were being carried over from other languages and laid down in C as ‘our style’.

Those sorts of habits get passed down the generations through maintaining the style of existing source, libraries and examples.

Also C11 still has a limitation that only the first 31 characters of an identifier are significant and it’s easy to break that without some abbreviation if writing truly portable code.

While longer names help readability of external identifiers, within blocks of code it’s common in many languages to use abbreviations. How much code is there like:

for(int index=0;index<size;++index)

Is it really so much more readable than:

for(int i=0;i<sz;++i)

Experienced programmers just get used to these idioms.

What is certain - length of identifiers do not affect speed of execution or size of executable code on any compiled implementation (the norm with C). Size will be affected if the executable embeds debugging symbols.

Generally, the length of a variable name should be inversely related to its scope. So a variable name whose scope is the entire program should be fairly readable. A variable name used in a short loop or small function can be very short. You will use the local, short variable names much more than the longer, global variable names. And contrary to what you might think, the shorter variable names are more readable.

If you have a small for loop, using i as an index is quite reasonable whereas something like loopIndexToPassedArray would be less readable, even if more descriptive. Further, the extra information contained in that variable name is already known, so it is just stating the obvious. The same considerations apply to names such as x, y,.. or p, q, r, … when restricted to local code. On some occasions it may be desirable to attach a comment at the point the variable is declared to establish constraints applying to its usage.

And Hungarian notation should be avoided at all costs. Hungarian notation is adding type information to a variable name. So instead of “firstName”, you might use “strFirstName”. The problem is that first it adds length to the variable name without really contributing much - with or without an IDE. But, worse, it causes update anomalies.

One of the worst ones is in Microsoft’s GUI interface, where a common function uses Hungarian notation to indicate the value is a 16-bit value. Guess what? It isn’t any more. But since that is now embedded in probably hundreds of thousands of programs - or even millions - there is no changing it. Changing a variable’s type without also needing to change the code happens on a regular basis. So, NEVER use Hungarian notation.

That said, some people suggest that there is a single exception. If the ONLY important information about the variable IS its type, then it might be reasonable. For example, assume that you have a function that performs the union of two sets. You might call the parameters “setX” and “setY”. But really, even that is a bad idea. Perhaps that code will be part of a class hierarchy, and may (eventually) used for bags (multi-sets) in the future. Bottom line, just don’t use Hungarian notation, it never helps and frequently hurts.

What you’re seeing is a general practice in programming, not just limited to C languages.

One common practice is to not use any real words. If you use a real word you might accidentally use a reserved word as a variable name. Even if it’s not a reserved word now, if your program ever gets ported to another language, it could end up being a reserved word later. While it might be easy to call something “date” or “size” or “year” … since these things could potentially be programmatic instead of descriptive, it’s better to avoid them.

Personally, I prefer the naming conventions that include datatype, which avoids that problem altogether: intSize

Naming conventions are important for readable code that avoids errors. I eschew plurals at all costs. I’ll use something like intSizegroup over intSizes. It’s just too easy to add or leave off an s and spend inordinate amounts of time hunting for the simple mistake. In my camelCase I prefer only one hump for the same reason, since languages can be case sensitive.

Additionally, programmers will also avoid variable names that are often used programmatically, even if they are not real words. For example, they wouldn’t just avoid using “length” as a variable name, they would also avoid “len” since len() is often a built in string function.

Because the name of the variable should not matter to the code reader
the way the variable is used should. Most variables with throw-away names
are temporary and do not need over-explanatory names.

Most Coders have at least a couple of college-level math classes they have taken,
and they model their variables on the math textbooks, that use a lot of x ,y, and z and so on.

It is logical to take a size_t variable and name it sz, often becuase there is a size() function around, and size is part of size_t and ssize_t, etc.

Traditionally i,j,k are counting variables, m,n, are matrix and array indexes,
x ,y, and z are intermediate result variables from algebra.
tmp gets used quite a bit (too much), but it signals to the reader and debugger that the value is not going to persist.

Where it becomes confusing, more descriptive names should be used.
int s = socket( a ,b, c); // pretty bad.

int  netsock = socket( AF_INET, SOCK_STREAM, 0); // typical

Here Enumerations are used to clarify and make things readable. The code is the same, just more human.

In college I found myself several times re-writing textbook code with descriptive
names to make it more understandable. Realize that the code produced is exactly the same. Red-Black Trees kicked my butt until I renamed all the variables to trace them through the code.

One technique I found helpful is to not change the existing code but copy the values at key places into helpfully-named variables and print out the values, etc.
Yes it is slow, but sometimes the hard way is the easy way.

I’ve never put this into words, but Quora User puts it perfectly:

Generally, the length of a variable name should be directly related to its scope.

So let’s say you have a variable which is used everywhere, say it represents the number of processors the computer has. You could call it “_numberOfProcessors”.

However, if you’ve got a loop in a function, you can have the iterator simply called “i”.

Or say you’ve got an iterator for rows and columns, have one called “rowi” and the other “coli”. You’ll probably find that it becomes more readable than having “columnsIterator” and “rowsIterator” everywhere.

Personally, I’d probably use “size” not “sz”, but I’d use “buff” instead of “buffer” or simply “fh” for a file handle.

If you use extremely descriptive variable names everywhere, then you can find yourself looking at a wall of text which is difficult to read. There is a balance of course, single-letter variable names everywhere will become hard to read too, but single-letter variables within short-lived scope can make those small functions and loops easier to read, as odd as it may sound.

Note: Quora User makes the excellent point that the length of a variable name is not actually inversely related to the scope of the variable.

As the Linux style guide for C/C++ opines:

C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand…

LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is non-productive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome.

In other words, C programmers tend to use short names because they’re used to it. It’s only harder to read if you’re not familiar with the conventions (e.g. using “i/j/k…” or “tmp” for loop counters/temporary variables is quite common). Though I’ll admit that even I think “sz” is not much shorter/better than “size”.

I can’t see that anyone has mentioned that short entity names were enforced because FORTRAN originally only had 6 character names (by the standard). This was a constraint imposed by the small memory footprint of compilers of the day.

Programmers somehow thought this was the way to write ‘code’ so it looked cryptic. 60 years later we are still trying to break this habit. Programmers should write programs, not code (producing code is the compilers job and it’s what computers are good at).

So this is not something limited by C or C programmers. Although I could say that C programmers do seem to think the less keystrokes the better. (You should not think of the whole world in terms of C.)

But that also depends on whether you are producing a long-lasting program that must be maintained, or a small once-off program. The two call for different levels of documentation (built into entity names).

Someone has pointed out that local names can be short because what they are is clear from the small context (there is a clue in that to writing correct software).

However, many local variables are superfluous and should not be used. For example:

b := a /= c

if b then …

no just write this directly:

if a /= c then…

or worse, I have seen

if b then

return true

else

return false

Using returns in this way is really bad, and not much better is:

return b

except as the last instruction in a function. So local variables should mainly be avoided anyway.

Because in the last millennium, when Hungarian notation - Wikipedia was invented, it looked like a good idea.

IDEs / editors weren’t nearly as powerful as today, so it helped you (to a certain degree) to understand the “real” type of some variable. And depending on the tooling you have available to you, there might still some benefit in using it today.

But of course: it makes code harder to read, so you want to be really careful about using it.

And even more of course: it might be valid for C code, but don’t use it in any other language, even C++ or so.

Only speaking for myself here, but I write code as if whoever has to read it will not have to depend on reading my mind in order to maintain it - regardless of whether I will be the “whoever.”

Sure, for simple loops I may use common indices like “i, j, k,…”, but if I’m using an index variable as a pointer (such as in the code I’m developing for a home-built raster-scan laser engraver) I will give the variable a more meaningful name. And several months (and projects) from now, I’m not going to remember that “i” means “column” and “j” means “row.” I think it’s false economy to use

for(int i=0; i<640; i++) { //i is column pointer

…

for(int j=0; j<640; j++ { //j is row counter

…

}

}

instead of

for(int column=0; column<640; column++) {

…

for(int row=0; row<640; row++) {

…

}

}

When I first read The C Programming Language, I just assumed that Brian Kernighan and Dennis Ritchie didn’t know how to type. So they used hunt-and-peck on the keyboard, thus preferring very short variable names. I further assumed that readers of the book just thought that was the way C should be written.

My reasoning has been reinforced by seeing the results of using keypads on small devices — IYKWIM

First of all, sz does not mean size, if you are using the Hungarian notation. It means zero terminated string. Is counterpart, st, means Pascal type string.

That's said, I grew up using the Hungarian notation at Microsoft. Although I got very accustomed to it, I never understood the need to have such short variable names, especially when programming in a language that compiles the code into an executable. When I program in an interpretive language, such as VBA, I do try to use the shorter names because they all get recompiled every time the program is run, and, thus, the program does not run as fast.

Now that I'm retired, I still write a lot of code, and I still use the Hungarian notation to prefix my variable names, but I now use long descriptive names since they make the code easier to maintain and they have zero effect on performance, for compiled languages like c. My personal opinion is that most programmers at Microsoft used short variable names because they didn't know how to type very well. I was always a pretty fast touch typer, and I felt I spent more time trying to make up a short name then simply typing out the name I wanted.

I am surprised that nobody answered that professional coders in C have naming conventions in their programs. And sz in C is used as a prefix and stands for « String terminated by Zero. The variable would be declared this way : char * szName;

i : integer / ui : unsigned int | int iCounter;

l : long / ul : unsigned long

b : boolean | boolean bTraceInfo;

p is usually added for pointers. « pl » means pointer to long | long * plAmount;

g usually means global variables :

char * gszDatabaseName;

And so on …

If you meet a coder who uses sz for « size », you should not trust him, and run away !!!

One reason is historical - the first linkers had limits of 6 to 8 characters for EXTERNAL symbol names - and if a linker had a longer limit of 8, the first character of C externals was often prefixed with an underscore (“_”) in order to prevent name collisions with assembly language routines (or others.)

Also, the symbol tables of early compilers was also constrained with similar limits.

The same kind of limits applied to other early compilers as well.

Together, this created a strong incentive for short symbol names. The standard C library has many names like this - like “stat()” and “errno”, “fopen()”, “printf”, and so on.

Of course these limits have long since been relaxed (or at least increased), but the legacy of the early names remains an influence.

• C is old
• In the past, displays were small
• Some style guides recommended to stick with N chars per line for « readability » Characters per line - Wikipedia
• Many coders in the beginning were mathematicians used to write short variable names on paper
• The editors did not had renaming refactoring features as they do have now (the shorter the faster to write/edit)

Now I would not consider this short naming practice as being still relevant. There is no benefits but the code size (But who cares) in having short names.

By experience, coders not understanding what they are doing often gives bad names, often one or two letters. This is common in POC, giving the right name involve to understand what you are doing.

Few exceptions exists like the loop where for instance it is common to use « i » instead or « index »

My feeling is that this comes from a place of paucity, and the ethos that goes with it. A lot of the C code that you see floating around is tied to hardware, and in a world where every byte counts, you end up being parsimonious when it comes to writing code and naming things. For example, there’s a method called atoi in the C standard library. Whoever wrote it could have called it stringToInteger. It would have been more descriptive, but they didn’t. And once you see that kind of parsimony in action, you begin to adopt a similar approach in your own programming style, with the result being what we have today.

Multiple reasons, but they start with the fact that naming variables is hard. It seems easy—just type whatever you want—but you want something that has several desirable characteristics:

• It should say what the value contained in the variable means
• It should be short so as to take little time to type and not eat up the whole line
• It should conform to existing cultural conventions about what certain variable names should be. Some of these conventions now stretch back almost 5 decades.
• It should conform to the coding standard being used for that piece of code
• It should be easy to come up with the name, i.e. the programmer shouldn’t spend a lot of time thinking up a variable name
• It needs to be easy to remember so you don’t have to keep figuring out what it means.

As you have no doubt noticed, these characteristics are often at odds with each other. That’s why coming up with variable names is so hard.

So, sz is pretty short. It’s also somewhat of a cultural convention, at least in some communities. But it could mean something else, so it’s got drawbacks. You could use size, sz1, Size, size_of_buffer, or any number of other names for the same thing.

It takes experience to come up with good names and, because of the conflicting desirable characteristics, there is no “right” answer. At the end of the day, however, your code has to be easy for the next person to understand, even when that person is you.

There are two complementary points that needs to be considered, one is that software development was beginnig, it was in its early days and much of our knowledge was being forged by trial and error.

Another point that on its working on a tty (ie. ASR-33) or punching cards are not so "user friendly" as using a modern editor with contextual auto complete and all other niceties we have today, so being concise would make you more productive.

Using small name for variables is more a tradition than a directive.