I would guard against "arguing from the extremes". I would think "on average" compact is more helpful. There are definitely situations where compactness can lead to obfuscation but where the line is depends on the literacy and astuteness of the reader in the specific subject as already pointed out by another comment. There are ways to be obtuse even in the other direction where written prose can be made sufficiently complicated to describe even the simplest things.

That's probably analogous to reading levels. So it would depend on the reading level of the intended audience. I haven't used C in almost a decade and I would have to refresh/confirm the precise orders of operations there. I do at least know that I need to refresh and after I look it up it should be fine until I forget it again. For people fluent in the language unlikely to be a big deal.

Conceivably, if there were an equivalent of "8th grade reading level" for C that forbade pointer arithmetic on the left hand side of an assignment (for example) it could be reformatted by an LLM fairly easily. Some for loop expressions would probably be significantly less elegant, though. But that seems better that converting it to English.

That might actually make a clever tooltip sort of thing--highlight a snippet of code and ask for a dumbed-down version in a popup or even an English translation to explain it. Would save me hitting the reference.

APL is another example of dense languages that (some) people like to work in. I personally have never had the time to learn it though.

Arthur Whitney writes compact code in C (and in k of course); most things fit on one A4 which is actually very nice to me as an older person. I cannot remember as much as I could (although i'm still ok) and just seeing everything I need to know for a full program on 1 page is very nice vs searching through a billion files, jump to them, read, jump back and actually mostly forgotten the 1000 steps between (I know, this refers to a typical overarchitected codebase I have to work on, but I see many of those unfortunately).

When I first read the K&R book, that syntax made perfectly sense. They are building up to it through a few chapters, if I remember correctly.

What has changed is that nowadays most developers aren't doing low-level programming anymore, where the building blocks of that expression (or the expression itself) would be common idioms.

I think the parent poster is incorrect; it is about precision, not about being compact. There is exactly one interpretation for how to parse and execute a computer program. The opposite is true of natural language.

Nothing wrong with that as long as the expected behavior is formally described (even if that behavior is indeterminate or undefined) and easy to look up. In fact, that's a great use for LLMs: to explain what code is doing (not just writing the code for you).

That's confusing because of order of operations. But

  while ( *(d++) = *(s++) );

is fairly obvious, so I think it gets a pass.

No, but *++d = *++s; does.