Thursday, July 01, 2021

Re: C style in OpenBSD

On Thu, 1 Jul 2021 19:09:28 +1000
Reuben ua Bríฤก <u5644051@anu.edu.au> wrote:

> > Date: Thu, 1 Jul 2021 13:51:21 +1000
> > From: Stuart Longland <stuartl@longlandclan.id.au>
>
> > Even someone who didn't know "C",
>
> ... seriously?

Yes seriously, there are people who write software computers, and do
not know C.

> > If you didn't know what a ternary was
>
> ... seriously?

If you've never needed to use one, why would you know about them?

Ternaries can look different in different languages too. In Python,
they're expressed as:

(true expression) if (condition) else (false expression)

Some languages do not have ternaries.

> > search.argmode = (
> > (strcmp(progname, BINM_MAN) == 0)
> > ? ARG_NAME
> > : (
> > (strcmp(progname, BINM_APROPOS) == 0) == 0)
> > ? ARG_EXPR
> > : (
>
> ... do you write:
>
> if
> else
> if
> else
> if
> else
> .
> .

`if` and `else` are more easily spotted by the eye than `:` and `?`.
If I wanted to write in meaningless symbols I'd use BrainFuck.

> no? then why do you write ? : in this style? it is the SAME logic,
> but the conditional is on the expression, not the statement.

It actually isn't… you can add braces to the if-else, and put
for/while/switch/if statements inside those braces to do more complex
logic if the need arises. Only mathematical expressions can be used
in ternaries.

So the if/else is infinitely more extensible than a ternary, whilst
_also_ being more readable because the eye will spot words like `if`
and `else` easier than single characters.

> my ? : indentation style is based on that usually used for else if

Go patent it then. I hear they'll patent anything these days.

> > Now, it should be immediately apparent why nesting this many ternaries
> > is a bad idea.
>
> Now,
> it
> should
> be
> immediately
> apparent
> why
>
> excessive indentation is a bad idea.

Right, I do not disagree there. I tend to use tabs for indentation and
limit my line length to ~80 characters for that reason: if I'm having
to use too deep-er indentation in a function, this is a hint to me that
maybe the function is getting too complex and should be split up or
re-factored to make it less complex.

Some argue that with wide-screen monitors 80 characters is rooted in
the past, and they have a point, but being able to fit two files
side-by-side on the same 1920×1080 monitor with a readable font size is
a big plus in my book.

> > Yeah, it kinda sucks there's no way to do a `switch` with strings,
>
> that is what my code does!

… badly.

> > I prefer to use brackets more than is strictly necessary.
>
> STYLE(9)
>
> Don't use parentheses unless they're required for precedence,
> the statement is confusing without them, or the compiler
> generates a warning without them.

"the statement is confusing without them" -- a subjective observation.
If you do C and nothing but C for a living, with one compiler on one
platform, then maybe, you know the operator precedence off-by-heart.

Most languages follow very similar precedence rules, so often things
just work anyway.

Occasionally, someone will slip an edge case in that you weren't
expecting, using brackets makes it abundantly clear, even to the
compiler/interpreter, what your intent is, a buggy compiler that
ignores operator precedence is not an issue so long as it processes
bracketed expressions properly, anyone with primary-school level maths
will understand what bits are to be computed first (even if they have
to look up what a particular operator does to its operands).

> > I do hope the coding styles you're showcasing to us aren't what
> > they're teaching at ANU.
>
> I AM NOT A COMPUTING STUDENT, TEACHER, STAFFER, etc.

Then stop acting like a first year CS student.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

No comments:

Post a Comment