And at the very least, "80-characters-per-line is a de-facto standard for viewing code" has been long wrong. As the post even mentions, 100 and 120 columns have been another popular choices and thus we don't really have any de-facto standard about them!
My opinion is that line width depends on identifier naming style.
For example Java often prefers long explicitly verbose names for class, fields, methods, variables.
Another approach is to use short names as much as possible. `mkdir` instead of `create_directory`, `i` instead of `person_index` and so on.
I think that max line length greatly depends on the chosen identifier naming style. So it makes sense to use 100 or 120 for Java and it makes sense to use 72 for Golang.
C code often use short naming style, so 72 or 80 should be fine.
C is the worst at naming length since everything is in the global namespace unless you're working on a teeny tiny project. So everything gets clunky prefixes to use as pseudo-namespaces or overly descriptive name to avoid conflicts.
Local variables sure, be short and terse. But that's common in most languages.
And you risk a collision for global identifiers, which cannot be reorganized in C. If some library had the same thought and defined `mkdir` first, your code can't define `mkdir` even as a private symbol. So you have to prefix everything and that contributes to the identifier length. In comparison, Go has a much better (but personally not yet satisfactory) module system and can have a lower limit.
Also on age, e.g. I began to prefer grandma font size from time to time for better focus, and that changes my workspace geometry.
For mkdir all-in, meh. It’s okay for mkdirp or rimraf, cause these basically became new words. But once you add more libs or code to a project it becomes a cryptic mess of six-letter nonsense. English code reads best, Java just overdoes it by adding patterns into the mix.
