I was wondering is there a reason C and C++ code favours comments over descriptive names? I'm almost certain i'm not making this up, but go into any random file here and look at the names. Structs will have members called p with a comment saying "position". It seems very silly.
My own rule of thumb is: short names for 'unimportant' variables where the meaning is clear from the context. More descriptive names for the more non-obvious cases, but still keep it short and concise (e.g. I would typically use "pos" instead of "position").
Having said that, some early C dialects limited the significant number of characters in identifiers to 6 or 8. I heard that this is the reason why the C runtime library function names are short (like strcpy() instead of string_copy()).
It does not seem silly to me. Coming from mathematics, single-letter variable names are the only acceptable possibility, especially in numerical code. I tend to read contiguous letters in a formula as products.
Besides, descriptive variable names violate the principle of "don't repeat yourself". It is better to describe the variable only once, in a comment next to its declaration, instead of several times.
Programmers should understand that not everybody who programs has a background in computer science, and certainly the traditional conventions of computer science are not universal and not generally reasonable. Many of us have a scientific background, where descriptive variable names are silly. We do not want our numbers to have meaning, that's the whole point of abstraction. Thus, they are named x, y, z, and so on.
For example, we have two competing coordinate systems: first is x // width, y // height, z // depth, and second is x // width, y // depth, z // height. With descriptive names we will have no such problem.
However, it's much easier to load large and complex algorithm into head if it written concisely: one letter per variable or function, minimum unnecessary separators. When I need to understand someone else codebase, I will often concatenate all files, delete all comments and obvious functions (getters, setters, eq, hash, etc.), abbreviate long names via search and replace, remove unnecessary symbols and convert functions and classes into oneliners, until I will see whole algorithm at once. However, reading of such code requires some additional training.
To summarize, it's possible and is easy to convert descriptive names into abbreviations, so, it's better to stick with descriptive naming in public interfaces.
force = (g_constant * mass[0] * mass[1])/(radius 2)
Communicates far more than the algebraic alternative.
Programming is about solving a particular problem, not providing a general formalism. The art of it, and mastery of it, is how to imbue the program with the problem domain. So that by speaking in its concepts you solve the problem.
> violate the principle of "don't repeat yourself"
That isnt the principle, that's a literal reading of each word conjoined into something totally different.
The principle is "solve the problem once", ie., if you encounter code re-solving a problem already solved before, abstract such that you solve it only once.
The principle only makes sense with respect to a problem which reoccurs, it is either incoherent or false when applied to literal fragments of code text.
One would then be moved to define replacement macros for anything more than two letters.
I respectfully, and strongly, disagree. Try to implement the conjugate gradient algorithm (or a variation of it) https://en.wikipedia.org/wiki/Conjugate_gradient_method Using your style, you will obtain an unreadable mess. Better make your code isomorphic to your math, and then explain the meaning of everything in the comments.
> force = (g_constant * mass[0] * mass[1])/(radius 2) > Communicates far more than the algebraic alternative.
I don't see how this is clearer than something like this
// Newton's law of gravitation
//
// m : mass of first body
// M : mass of second body
// G : universal gravitational constant
// r : distance between the two bodies
// F : force between the two bodies
F = G * m * M / (r^2)Descriptive variables are about maintainability. And when it comes to the latter, the guiding principle is:
> Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
I've tried many times over the years, but I just never seem to be able to squeeze all the relevant information into the names without making them excessively long, and even then I usually find upon rediscovery that I have omitted an important detail. Mathematics seems to thrive on a kaleidoscopic abundance of subtle but important variations on similar themes and this really frustrates the ability to encode information in the names. Also, the necessity of building an abstract-mathematical mental picture separate from the code obviates the need. The value proposition of verbose naming conventions entirely falls apart under these conditions, and once it does, the benefits of concision rule the day.
If all you have is a 300 baud terminal (a luxury for some early users), writing a 30-letter statement takes about a second. Doubling that speed by using shorter identifiers is worth it (certainly as long as all the people reading the code either wrote it, or have the writer sitting next to them)
That created a culture that persists to today.
There are different cultural streams such as Apple’s one, which originated in Pascal (for the original Mac OS). Consequently (I think), Apple’s C headers later on weren’t afraid to use identifiers with over 40 characters. Next step/Cocoa similarly aren’t afraid of long names (https://mackuba.eu/2010/10/31/the-longest-names-in-cocoa/)
Looked at several headers at random just now (including file, net) and they seem OK. Not terribly verbose, but not exactly cryptic.
In terms of 'p' vs 'position' - 'p' is an extreme and it's usually used for pointers, but the driving factor for using shorter names is usually to keep the line length in check when these vars are used in the code. Ditto for type names.
"Position" is quite often shorten to "pos", "offset" to "off", "length" to "len", etc. This is very common. Sometimes the original name is too long (e.g. "position of the last error in the first block") and lands itself to a not-so-obvious abbreviation, in which case the comment is made to clarify what it is.
It's basically about striking a balance between succinctness and verbosity, and conventionally C tends to lean towards the former.
Neither ::highres nor ::high_resolution_clock really is a descriptive name though, because it doesn't really describe what it means. What is a "high resolution clock" here? Does it mean µs resolution? Nanoseconds (as some "newer" Linux APIs support)? What about accuracy?
"chrono" is one of these "sounds cool but is kind of a weird word to use" things.
And of coure any new C code would look out of place if it didn't follow these old shibboleths... better make new C code an unreadable mess too, no? ;)