There is a balance between `*p` and `inputPointerToMiddleOfBufferThatFrobnicates`.
Very true, or as I like to put it: everything is a tradeoff.
Over decades of programming, I'm fairly certain my preferences for things like function/identifier length could be plotted along a damped oscillation curve. :)
> Also related: (in particular local) identifiers and names should be short.
The general idea is that the more distant the identifier is, the more descriptive is should be. Because you don't have as much context, and it is also a hint: if you see a long, descriptive name, it is more likely to be global.
And descriptive doesn't mean long. You still need to try making your descriptive names as short as possible. For example "timeSinceMidnightInSeconds" can be shortened to "secondsSinceMidnight" without loss of information: seconds are a unit of time, no need to repeat it.
I don't thing good names will be solved soon
When somebody says "short identifiers" in relation to C, this is exactly the style meant by that, not the cryptic style of C standard library.
To be fair, this is more doable in C than most other languages. No namespacing, no generics, etc. means you're not using as many columns.
I'm still not convinced, though. It's a crunch. Would rather just set a 120 to 160 column limit and make identifiers as descriptive as they should be. And I'd use prefix namespacing all over the place anyways -- fuzzy autocomplete can make it convenient.
"Identifiers should be short" when I've mostly seen people decry how annoying it is to find yourself in a codebase where everything is abbreviated C-style (htons, strstr, printf, wchar_t, _wfopen, fgetws, wcslen)
There's a case for more verbosity and if you look at modern Curl code it reflects that as well, new identifiers aren't short
https://github.com/curl/curl/blob/master/lib/vquic/vquic.c
"Functions should be short" where I've mostly seen very negative feedback on codebases written following the trend of Uncle Bob's short functions. Complaints that hiding code in 10 levels of function calls isn't helpful, and that following rabbit holes is tedious even with modern editors
"Code should be narrow", "we enforce a strict 80 column maximum line length" I don't think I've seen that take lately. I remember seeing a few posts fly by about the number 80 specifically
You want to prevent dragging your eyes. For my IDE on default settings on a 1080p monitor, half of a 15" screen fits 100 characters
If you take away 20 columns to fit your text on less of the screen do you really get any benefits
What about the cascading effects on the code, like worse names, split lines, ...
In the end it's semi-interesting but we're all building sheds and these are mostly debates on what color the shed should be