[rescue] Python > 3.6 on Solaris 10

[Peter Corlett]

On Mon, Oct 18, 2021 at 11:42:40AM +0200, Liam Proven wrote:
[...]
> https://en.wikipedia.org/wiki/Indentation_style

> K&R style & its variants 1TBS (OTBS), Linux kernel, mandatory braces,
> Java, Stroustrup & BSD KNF. Then Allman & Allman-8 style. Then the
> Whitesmiths, GNU, Horstmann, Pico, Ratliff & Lisp styles.

> I mean WTABF.

I posit that the Haskell and Lisp examples listed are transcribed from
Haskell and Lisp syntax and are not used in brace-delimited languages.
Further, many of the others are uncommon or project-specific and date back
to when we were still figuring out these things.

Most code I encounter seems to be more or less K&R: modern machines have
16:9 or 16:10 widescreen displays, applications and operating systems add
menubars and toolbars to the top and/or bottom, and this leads to styles
which aren't profligate with vertical space if the developer wants a
reasonable amount of code on screen at once.

Occasionally you find some code which defies categorisation. Procmail is my
usual go-to when highlighting C on crack. Check out this beauty:
https://github.com/Distrotech/procmail/blob/master/src/regexp.c

[...]
> The *only* way to fix it is to make it matter: make it significant. If
> making your language readable is a primary consideration, more important
> than terseness or anything, then you *must* make everyone use the same
> indentation style. If it's possible to change it, somebody will. If your
> editor forces it, they'll change editor, whatever.

I see that you're firmly in Team Python :)

There are many reasons I don't like Python, and significant whitespace is
high on the list. It's fine for small, well-designed programs, but Python
developers tend to be quite junior and after a while their code gains far
too many levels of indentation ("helper functions, we've heard of them"),
making it much harder than it should be when I'm dragged in to "just help
add this one simple feature they're struggling with" which turns out to need
a major refactoring and I have to be extremely careful to correctly indent
and dedent the right lines the right number of levels to not totally wreck
the code. Significant whitespace is just too brittle for real-world code,
and the only good place for it is in trivial pseudocode in academic papers.

Python's significant indentation has a possible upside in that it doesn't
waste vertical space on a line containing a closing brace, but that line
should probably be left blank for readability anyway. After all, we organise
prose into paragraphs rather than smush everything together.

> The *only* way to make it impossible for programmers to roll their own
> indentation is to make the indentation meaningful. To make it part of the
> syntax. Then everyone _has_ to use the same.

The other way is to mandate that all code be run through a source-tidying
tool to ensure consistency. This can be enforced via the version control
system, although peer pressure is often sufficient.

The C languages are too fragmented for any particular formatting tool and
style to be the de facto standard, but Rust has rustfmt, Perl has perltidy,
and so on, so there's less to argue about. clang-format is quite nice if you
need to use one of the languages it supports and get to choose the
formatting tool.