Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes)

[G. Branden Robinson]

At 2024-11-19T01:47:33+0100, onf wrote:
> On Tue Nov 19, 2024 at 12:37 AM CET, G. Branden Robinson wrote:
> > At 2024-11-18T21:43:24+0100, onf wrote:
> > > [...]
> > > Just a small nitpick, but you should probably do s/(warning) /\1/.
> >
> > Yes, that was a code style goof.  Thanks!  Fixed.
> 
> Hopefully the way I suggested...

Yes.  Clark's coding style is not the one from the GNU Coding Standards,
with the weird brace indentation.

Personally, I have a strong distaste for jamming parentheses up against
control structure keywords, like `if(` or `switch(`, though I know some
disciples of old-school Bell Labs code will cling to it unto death.

I also strongly dislike putting a space between a function name and its
parenthesized argument list.  I believe some people prescribe this
practice because they're aware that doing so will escape expansion of a
preprocessor macro, and they "want to be sure they get the function".  I
think there are multiple things wrong with that view.

Unless what you're defining _is_ the macro shadowing a function, you
shouldn't care whether you're expanding a macro or calling a function.
Encapsulation is good.  If the macro breaks the function interface, the
macro is buggy and should be fixed, not avoided.

Also, the use of whitespace to change the semantics of a program is
horrible.  (I can tolerate Python's semantic indentation rule, but this
_is_ one of the grounds upon which people hate it.)  `foo (bar)` vs
`foo(bar)` is much too subtle, especially combined with the derpy
`if(foo)` notation so beloved in some places.

Rust has a better idea.  If you define a macro, it gets a `!` at the end
of its name (or maybe more precisely as part of its interpolation
syntax).  Hard to miss and it even kind of shouts at you to get your
attention and rouse you from your lull.

> GNU's code style guides tend to be awful.

I'm aware of only one.  I don't work on any projects that use it, but
that's mainly happenstance.  Maybe the only place GNU brace style is
really enforced is Emacs, because that's where RMS will notice it.

> I like the nickname sometimes given to C++, swiss army chainsaw.
> Be careful or it will cost you an arm and a leg... :)

Yeah.  Thanks to groff I have regular encounters with Leatherface.

> > [...] C-like OOP languages [...]
> 
> Sounds like an oxymoron to me. Although some OOP constructs are
> possible in C, they don't come very naturally to the language. Perhaps
> you meant C++-like? [1]

No, I mean languages that crib their gross syntax from C, such as its
use of braces for statement grouping, which is a lot of languages.

All of C, C++, Java, and C# are similar in this respect, and I regard
them as being in the same family in this sense.

Another tradition is that of Algol/Pascal/Ada.

My favorite criticism of the latter family by advocates of the former is
that braces are more efficient because they're so much easier to type
than "begin" and "end".

My response is that any programmer whose productivity is substantially
affected by the speed with which they can type "begin" and "end" versus
"{" and "}" is _not_ someone I want to work with.  In my view, a
software engineer worthy of the title spends much more time thinking
about, revising, testing, and DOCUMENTING existing code than blasting
out a write-once, read-never prototype before shotgunning his twentieth
can of Red Bull that night and slamming it down with a scream as the sun
comes up and he roars to his next rock star gig in his
Mustang/Camaro/Challenger.

> [1] Contrary to what many people think, there is no such thing as
>     C/C++, because C++ is not a complete superset of C.

The truth value of that statement depends on the domain of discourse.
C's and C++'s syntaxes much more closely resemble each other than, say,
either's does *roff.  But I would agree that it's dangerous to assume
that any non-trivial exhibit of code written in one language that
happens to compile without diagnostics in the other preserves its
semantics.  Even some of the trivial cases will change meaning (what's
the `sizeof` a character literal?).

Regards,
Branden

signature.asc
Description: PGP signature