Do you mean like using `fp` for a file pointer or `fd` for a file descriptor? That is idiomatic, and I would consider calling them `filePointer` or `fileDescriptor` to be an obvious smell that the developer doesn't know what they're doing.
I'll do something like:
int epollFd = epoll_create1(0);
OP has a point. We could do with more discipline when it comes to naming conventions in C. We're not using punch cards any longer.
Somewhat related, there's another comment about the 80 char max... clang-format keeps to this. I'm kind of OK with this particular remnant of punch cards because I can get four editor windows open side by side on my ultra wide monitor.
The nginx codebase is pretty freaking fantastic and I've learned a lot from just randomly browsing through the source, but I mean, come on:
https://github.com/nginx/nginx/blob/master/src/core/ngx_arra...
if ((u_char *) a->elts + a->size * a->nalloc == p->d.last) {
If that read:
if ((u_char *) array->elements + array->size * array->nalloc == memoryPool->d.last) {
Even after that you had compilers with limits like 6 character names for a symbol.
Those constraints went away, but names made to be comfortable for the users of teletypes and ancient compilers stuck around, and people made more of them because it fit the preexisting theme.
And now it's just plain inertia, where it keeps on going because that's what it looks like in the books, so students imitate it.
That's more than inertia, that seems to cross the threshold for ceremony. When was the last time that actual printers/teletypes were used, the 60s?
The inwrtia part of it is people imitating what they already see on a project (cause why would you disrupt something as a newcomer on a project) and line length rules which I've seen come up from time to time along the years (not sure if a 120 character line length is enforced nowadays within the kernel)
After you've grokked it the first time, e.g. "dgemm" is much more convenient than "double precision general matrix multiplication". This is akin to speaking aloud "DC" versus "The District of Columbia". Uses far outweigh learning.
Consider even Python calls it a "dict" not a "dictionary" because the latter is a mouthful. Though what was wrong with "map" I often wonder.
A conflict with the map() function maybe?
No. I like these names as it's just easier to read. fp or fd is short and to the point, and "filePointer" or variants thereof add noting except more characters to read, more "wall of text"-y code that's harder to scan, etc.
And I don't really want to have a discussion about it as such; whatever your preference is that fine. I'll be happy to adjust to whatever works well within a team. But I wish people would stop spreading nonsense like this to invalidate other people's preferences.
I definitely make a point of using only single-letter variables in most of my C and python programs.
It is a very common usage in scientific computing. In math, all variables are single letters. Always. If a variable has more than one letter, you read it as the product of several variables, one for each constituent letter. When you are translating a formula that reads "y=Ax", you want to write something like
y = A * x
output = operator * input
output = linalg.dot(operator, input)
Mathematics itself used to be like that in ancient times. But after centuries of distillation, we arrived to the modern efficient notation. Some "programmers" want us to go back to the ancient ways, writing simple formulas as full-sized English sentences. But they will take single-letter variable names from our cold, dead hands!
Of course, the first appearance of each single-letter variable must be accompanied by a comment describing what it is. But after this comment, you can use that letter as many times as you want. Encoding that information in the variable name itself would be disturbingly redundant if you use the variable more than once (which will be always the case).
However that particular use-case has become dramatically less significant.
Terse notation has nothing to do with manual handwriting. Modern math books and articles are still written by computer using a very terse symbolic notation, which has been developed during the last six centuries. Originally, the symbols +, = were shorthand abbreviations of Latin words.
I guess computer scientists want to re-invent everything from scratch. How long will they need to evolve from "LinearAlgebra.matrixVectorProduct(,)" to the empty string? I hope it's less than six centuries!
Mathematicians seem to miss the difference between math and code quite often. The former provides the solution to a well-understood problem in a straightforward manner. The latter transports an abstract concept, a plan, a state of thought to the reader. A neat side effect is making computers go beep. In that context, being as clear as possible is really important.
When I code, I prefer comments explaining the general idea of what’s happening and why in a given folder/file/section (not explaining each line) combined with terse code.
Example:
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
func copy(f *os.File) { … }
I think f is more than clear enough as a parameter name. The same can be said of variables where the type is easily inferred from the declaration or initialization.
Apple has one 82 characters.
https://developer.apple.com/documentation/contacts/cnlabelco...
On the other hand when you are dealing with a file pointer in a language that deals with file pointers constantly, “fp” is meaningful enough.
CN_LCR_BiaoMei = 77,
// either mother's sibling's daughter or father's sister's daughter
// aka female cousin involving at least one female parent
A lot of lisp material features single letter vars, for example. (Actually, var length in prod code bases seems related to scope. So toy examples with obvious context see single letters strewn about. But digging through the classic books will rub off on the budding programmer...
Here's the very opinionated documentation: https://www.kernel.org/doc/html/v6.5/process/coding-style.ht...
I also want to note that the 80 columns limit was bumped to 100, and is no longer strictly enforced: https://www.phoronix.com/news/Linux-Kernel-Deprecates-80-Col
C - not so much. In C you are more likely to see acronyms. It's also interesting that for some reason, macro names are spelled out in full, but function names are abbreviated. So, typical C looks like:
LONG_SCREAMING_MACRO_NAME_(uh, oh);