Comment by sebstefan | Hacker News Reader

Comment by sebstefan | Hacker News Reader

Parent Full thread

The guidelines feel out of sync with the directions I've seen people push coding styles over the years

"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

Everything is a balance. IMHO, the "identifiers should be short" "functions should be short" and such are knee-jerk reactions to overly long things that are common in some other languages (looking at you, Java). Like the practice of indicating the type, pointer, etc. Stuff ike `pWcharInputBuffer` and such.

There is a balance between `*p` and `inputPointerToMiddleOfBufferThatFrobnicates`.

>Everything is a balance.

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. :)

> https://github.com/curl/curl/blob/master/lib/vquic/vquic.c

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.

> "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

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.

For short identifiers, I think you missed an important detail.

> 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.

Seems similar to the linux kernel coding style: https://www.kernel.org/doc/html/latest/process/coding-style....

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

I don't thing good names will be solved soon

Reply on news.ycombinator.com