From Newsgroup: comp.os.vms

On Sat, 23 Aug 2025 23:49:14 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Sat, 23 Aug 2025 19:45:19 -0400, Arne Vajh|+j wrote:

1) VMS Basic using = for both assignment and equal comparison,
while most other languages use different symbols (= and ==,
:= and =, = and .eq., ...)

But they only apply to non VMS Basic developers.

Nearly all BASICs were like that, including I think Microsoft BASIC.

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/24/2025 10:34 PM, Lawrence DrCOOliveiro wrote:

On Sat, 23 Aug 2025 23:49:14 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Sat, 23 Aug 2025 19:45:19 -0400, Arne Vajh|+j wrote:

1) VMS Basic using = for both assignment and equal comparison,
while most other languages use different symbols (= and ==,
:= and =, = and .eq., ...)

But they only apply to non VMS Basic developers.

Nearly all BASICs were like that, including I think Microsoft BASIC.

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-25, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/24/2025 10:34 PM, Lawrence D?Oliveiro wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

Just don't try getting that code past me without first having used
brackets around the subexpressions. :-)

But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/26/2025 8:30 AM, Simon Clubley wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/24/2025 10:34 PM, Lawrence D?Oliveiro wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

Just don't try getting that code past me without first having used
brackets around the subexpressions. :-)

I would also do:

('0' <= ch <= '9') or ('A' <= ch <= 'F') or ('a' <= ch <= 'f')

But the problem is not in the OR of 3, but in the chaining comparison
(special interpretation of two comparisons)

But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

I am all for shoveling lots of parenthesis's all over the code to
make it really obvious.

But in this case the chaining comparison itself provide some
weird cases.

I prefer the alternative of:

(ch in '0'..'9') || (ch in 'A'..'F') || (ch in 'a'..'f')

or maybe:

ch in [*'0'..'9', *'A'..'F', *'a'..'f']

if the language support that (Groovy does).

I think it is just as readable and it does not require
the chaining comparison (special interpretation of two
comparisons) that result in some weird cases.

The chaining comparison does have one advantage though - it
works with floating point. But I can live with having to
write floating point intervals the traditional way.

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 26 Aug 2025 19:38:40 -0400, Arne Vajh|+j wrote:

I am all for shoveling lots of parenthesis's all over the code to make
it really obvious.

There is a cleaner way of making structure obvious.

Hint: the page/screen has two dimensions, not just one.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/24/2025 10:34 PM, Lawrence D?Oliveiro wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

Just don't try getting that code past me without first having used
brackets around the subexpressions. :-)

Well, brackets would break it:

1 < 3 < 4

True

1 < (3 < 4)

False

If you want add "can not use brackets inside" as bad feature of Python chaining.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-25, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/24/2025 10:34 PM, Lawrence D?Oliveiro wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

Just don't try getting that code past me without first having used
brackets around the subexpressions. :-)

But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/24/2025 10:34 PM, Lawrence D?Oliveiro wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

Yes.

But note that the feature is not "interval comparison" but
"chaining comparison operators".

The above example is very readable and makes sense.

Just don't try getting that code past me without first having used
brackets around the subexpressions. :-)

But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

[snip]
But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

[snip]
But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

If you are an employee you either comply, find a new position
or get fired. No real trick at all.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <mhdru9F9t36U2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-25, Arne Vajh|+j <arne@vajhoej.dk> wrote:

[snip]
But it is less obvious with other operators.

Example:

4 == 4 == True

Most languages (possible all exception Python) evaluate
that to True, because it is treated like:

(4 == 4) == True

But it is False in Python because it is treated like:

(4 == 4) and (4 == True)

Which feels less natural.

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

If you are an employee you either comply, find a new position
or get fired. No real trick at all.

Well, yes and no.

That is a very simple take, and it's true in some sense, but
omits the background work to make it happen.

Someone in a position of influence and authority needs to define
the style and everyone needs to agree to adopt it. That does
not just happen; someone needs to make it happen. And getting
to that point can be a challenge, particularly if you want it to
work at scale (MLOC or BLOC sized code bases) with many
programmers across different teams working on a shared source
repository simultaneously.

Moreover, in large codebases, someone off in a corner somewhere
might be writing code that doesn't get the same level of
scrutiny that other code gets; ensuring uniformity is more of a
social process (and thus hard) than an engineering process
(which is easy in comparison); automated tooling can help, but
it really needs to be part of the organizational culture.

Finally, the norms and expectations need to be documented, and
it needs to be not so onerous that it's de facto ignored.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

You write them for the people who come after you who have to
maintain and extend them. People who have a good understanding
of the language but may have your level of expertise/knowledge/skills.

You write them for the people who understand most of the algorithms
involved, but maybe not at the level you do.

You also write them for yourself a couple of years from now and who
is now looking at this code written a couple of years ago and is now
wondering which &*%&^% idiot wrote this code like this in the first
place :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

You write them for the people who come after you who have to
maintain and extend them. People who have a good understanding
of the language but may have your level of expertise/knowledge/skills.

"may NOT have your level". Sorry. :-)

You write them for the people who understand most of the algorithms
involved, but maybe not at the level you do.

You also write them for yourself a couple of years from now and who
is now looking at this code written a couple of years ago and is now wondering which &*%&^% idiot wrote this code like this in the first
place :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 2:51 PM, Simon Clubley wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

You write them for the people who come after you who have to
maintain and extend them. People who have a good understanding
of the language but may have your level of expertise/knowledge/skills.

You write them for the people who understand most of the algorithms
involved, but maybe not at the level you do.

You also write them for yourself a couple of years from now and who
is now looking at this code written a couple of years ago and is now wondering which &*%&^% idiot wrote this code like this in the first
place :-)

There is an old joke that goes something like this:

"5 years ago when I wrote this code only God and myself
understood how it worked. Now only God understands it."

:-)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108ssrb$24jsc$7@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

You write them for the people who come after you who have to
maintain and extend them. People who have a good understanding
of the language but may have your level of expertise/knowledge/skills.

You write them for the people who understand most of the algorithms
involved, but maybe not at the level you do.

You also write them for yourself a couple of years from now and who
is now looking at this code written a couple of years ago and is now >wondering which &*%&^% idiot wrote this code like this in the first
place :-)

This is all true. I think one might paraphrase this as meaning
that you write code for the programmer that is slightly below
the median, and only hire engineers at median level or higher.

But this is slightly different than what I meant, which might be
similarly reframed as asking, how does one figure out what
"median" means? What is the base level of competence one might
assume when working on any given project/codebase/etc?

For instance, this demonstrably differs between organizations; I
would argue it often varies across projects within an
organization as well, and probably even within a project as the
project evolves over time. So how does one calibrate the median
point to which one targets ones programming standards, and how
does one ensure that it remains applicable?

E.g., am I writing assuming a new-grad with almost no industry
experience and under-developed programming proficiency? Do I
assume your typical application developer who does CRUD-backed
web sites/business applications? Published researchers with deep
domain expertise but only research-quality programming
experience? Sophisticated systems programmers who regularly
work on kernels and compilers? PhD level computer scientists
with extensive non-research programming experience?

The way I write code, and the level of proficiency I expect with
specific tools, is going to be qualitatively different when
working with any of these groups. I've spent the bulk of my
career working with the last two groups I mentioned above, and I
will rightly expect a much higher level of expertise, rigor, and
programming sophistication and quality from them than I will
from new grads. Similarly with researchers: I'll expect them to
_know_ more in absolute terms, but they have very different
pressures and constraints, so their code will likely be of lower
overall quality. My experience is that the application people
working on business/CRUD programs have the widest skills
variation between individuals.

So the way that I write software is likely to be far different
between projects/teams and across organizations. If I am
working on a project where excellence is the norm, then
parenthesizing every boolean expression is going to be tedious
and actually slow folks down; if I'm assuming all new-grads,
less so.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

I doubt that.

I would expect with parenthesis's:

actually read expression : 2 second
thinking "nice to see good craftmanship" : 1 second

and without:

actually read expression : 1.9 second
thinking "arghh - this code looks written in hast - should I raise an
issue? No - there are probably more important issues!" : 3 seconds

:-)

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <68b2087a$0$712$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

I doubt that.

I would expect with parenthesis's:

actually read expression : 2 second
thinking "nice to see good craftmanship" : 1 second

if ((a == 6) || (a == 7)) {
// do the thing...
}

"Huh; I wonder why they parenthesized `a == 6` and `a == 7`....
the operator precedence is obvious, so what am I missing here?
I'd better check the surrounding code to see if there's
something thing that I am not accounting for here...oh god, `a`
isn't some kind of weird macro, is it? No...that doesn't make
any sense, and besides, I see it declared as an `int` 30 lines
up.... What was this programmer thinking? It looks like it was
written by someone who just read a Steve McConnell book for the
first time. It's actually harder to read this way, and doesn't
match the predominant style in the rest of the code base. Do
they actually know the language?"

and without:

if (a == 6 || a == 7) {
// Do the thing.
}

"Ok. If a is 6 or if a is 7, then do the thing."

actually read expression : 1.9 second
thinking "arghh - this code looks written in hast - should I raise an
issue? No - there are probably more important issues!" : 3 seconds

:-)

I feel like the above is quite real, and something I've
encountered recently.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 5:44 PM, Dan Cross wrote:

In article <68b2087a$0$712$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

I doubt that.

I would expect with parenthesis's:

actually read expression : 2 second
thinking "nice to see good craftmanship" : 1 second

if ((a == 6) || (a == 7)) {
// do the thing...
}

"Huh; I wonder why they parenthesized `a == 6` and `a == 7`....
the operator precedence is obvious, so what am I missing here?

Not being an expert.

There are experts that like to drizzle parenthesis's out
over the code.

There are experts that do not like to drizzle parenthesis's out
over the code.

There are no experts that has never heard of the practice of
drizzling parenthesis's out over the code.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 29 Aug 2025 19:01:21 -0400, Arne Vajh|+j wrote:

"Huh; I wonder why they parenthesized `a == 6` and `a == 7`....
the operator precedence is obvious, so what am I missing here?

Not being an expert.

Not knowing how to keep docs handy?

You donrCOt have to keep all the necessary knowledge in your head. But you *do* need to know where to find it when you need it.

Oh look, IrCOm not the only one who thought of this: <https://en.cppreference.com/w/c/language/operator_precedence.html>.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108tbg1$29q30$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 5:44 PM, Dan Cross wrote:

In article <68b2087a$0$712$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

I doubt that.

I would expect with parenthesis's:

actually read expression : 2 second
thinking "nice to see good craftmanship" : 1 second

if ((a == 6) || (a == 7)) {
// do the thing...
}

"Huh; I wonder why they parenthesized `a == 6` and `a == 7`....
the operator precedence is obvious, so what am I missing here?

Not being an expert.

Aha. So now we're back to my question, "for whom are we writing
this code?"

In some code bases, it's acceptable to say, "not for experts."
In others, less so. That is to say, there are some code bases
which are not meant for non-experts. In that case, one should
bias towards writing code for experts, not for novices.

Btw, you snipped the rest of the context, particularly the part
where I wrote, "this is unlike the rest of the code base" (or
words to that effect). Often times, similarity to existing code
is frankly more important than whether one puts parentheses
around _every_ boolean expression.

There are experts that like to drizzle parenthesis's out
over the code.

There are experts that do not like to drizzle parenthesis's out
over the code.

There are no experts that has never heard of the practice of
drizzling parenthesis's out over the code.

But there are experts who look at that, realize that this code
was not written for experts, and be slowed down wondering why
novices are messing with something that they should not, without
a lot of supervision.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 8:22 PM, Lawrence DrCOOliveiro wrote:

On Fri, 29 Aug 2025 19:01:21 -0400, Arne Vajh|+j wrote:

"Huh; I wonder why they parenthesized `a == 6` and `a == 7`....
the operator precedence is obvious, so what am I missing here?

Not being an expert.

Not knowing how to keep docs handy?

Given that we are talking about people that do know the
operator precedence, then that aspect is not particular
relevant.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

Yes.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

It does not take that much to get coding conventions
followed.

If >5% of code is reviewed and not following coding
convention get flagged and the guilty get asked to fix
the code *and* other code that has same problem, then
in a few months everyone is following. The risk of
non compliance eventually being detected and the hassle
of doing the fixes makes it easier to do the right
thing the first time.

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <68b2549f$0$718$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both.

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

Yes.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

It does not take that much to get coding conventions
followed.

Statements like this beg the question, what is the largest
project you have worked on, and with how many other engineers?
I am asking sincerely, by the way; that's not a dig.

I once worked in a, at the time, 2BLOC monorepo with ca O(10^5)
programmers working in it concurrently in ~20 engineering
offices spread across the globe.

A tiny subproject within that was ~1MLOC split between about 500
KLOC in C++, and the other 500 KLOC in Common Lisp; HC was
around 20 FTEs mostly in a single office.

The local style guide mandated that the maximum line lenth in
Lisp was 100 characters; I counted and estimated that at least
20% of lines had more than 110 characters.

That project came through an acquisition, and the code was
inherited. On the other hand, the rest of the organization had
_very_ rigorous code style rules for various languages (five
officially supported languages, and a dozen or so other,
unofficially supported languages) and gated integration
verifying compliance with those rules through both review and
automatic tooling. In that code base, style violations were
exceedingly rare.

Incidentally, in the Lisp project, there were no automated
unit-level tests, as the team had bought completely into the
myth of incremental, REPL-centric development. Which meant that
every single time I made a change in that code I found an
existing bug. Every. Single. Time. There was a large body of
integration tests, but running the test suite took about 3 hours
on a very beefy workstation, so reasonably a programmer could
get two integration runs a day.

The rest of the organization, in contrast, had a strong culture
of automated batch unit testing, and successful CI was required
for commiting a change. Tooling existed that could compute the
transitive closure of the dependency graph for any given change,
so all relevant tests could be run; integration was blocked if
any failed.

Guess which side of the house had a lower overall defect rate
and higher developer velocity?

But this is the difference between making something a strong
part of the organization's cultural norms and supporting it with
tooling and just wishing the problem away.

If >5% of code is reviewed and not following coding
convention get flagged and the guilty get asked to fix
the code *and* other code that has same problem, then
in a few months everyone is following. The risk of
non compliance eventually being detected and the hassle
of doing the fixes makes it easier to do the right
thing the first time.

That's cute, until managers step in and tell you to igore all of
that, because they've got a customer breathing down their neck
to get a feature they need into production. It also shows a
distinct lack of respect for your engineers.

As part of the build process for that Lisp project I mentioned,
an automatic linter ran that flagged style violations. There
were so many that the output was so voluminous that it was
universally ignored.

The point is that you really need to inculctate respect for the
value that comes from rigorous adherence to those rules, and
support it with tooling so that they are easy to comply with
(and there are meaningful consequences for igoring them---like
your change just can't be submitted). Otherwise, they will just
be ignored, and attempts to force them by making people do a
bunch of grunt work if they're caught violating one will
backfire.

The "culture of fear" approach that you and Bill both seem to be
advocating simply does not scale, especially once it runs
headlong into the reality of the business considerations that
come with taking engineer time to do a bunch of busy work to
fix something that somebody else did.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

This is all true. I think one might paraphrase this as meaning
that you write code for the programmer that is slightly below
the median, and only hire engineers at median level or higher.

But this is slightly different than what I meant, which might be
similarly reframed as asking, how does one figure out what
"median" means? What is the base level of competence one might
assume when working on any given project/codebase/etc?

For instance, this demonstrably differs between organizations; I
would argue it often varies across projects within an
organization as well, and probably even within a project as the
project evolves over time. So how does one calibrate the median
point to which one targets ones programming standards, and how
does one ensure that it remains applicable?

You could always create a "!!!Change_Skills_Required.README" in the
project (or subproject) root directory, stating with specific detail
what skills, knowledge, and experience level, are required before
it is appropriate for someone examining the project to start work
on it. Include references to appropriate papers or tutorial and
background material. Include the actual material in a references/
directory tree if appropriate.

Also include contact details for advice when they get stuck. Try to
list departments or teams instead of specific people if possible.
People change roles much more quickly that the overall team or
department does.

So the way that I write software is likely to be far different
between projects/teams and across organizations. If I am
working on a project where excellence is the norm, then
parenthesizing every boolean expression is going to be tedious
and actually slow folks down; if I'm assuming all new-grads,
less so.

You could also state this initial target audience in the above document.

Simon.

PS: I'm actually serious about this. _You_, as the original team or
person to create a project, then get to set what is expected before
someone later on starts work on the project.

This stops that future person from having to guess what skills are
required and then finding out the hard way that they are in way over
their heads. It also avoids having to ask the questions you are
asking here.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10943ve$3r9go$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

This is all true. I think one might paraphrase this as meaning
that you write code for the programmer that is slightly below
the median, and only hire engineers at median level or higher.

But this is slightly different than what I meant, which might be
similarly reframed as asking, how does one figure out what
"median" means? What is the base level of competence one might
assume when working on any given project/codebase/etc?

For instance, this demonstrably differs between organizations; I
would argue it often varies across projects within an
organization as well, and probably even within a project as the
project evolves over time. So how does one calibrate the median
point to which one targets ones programming standards, and how
does one ensure that it remains applicable?

You could always create a "!!!Change_Skills_Required.README" in the
project (or subproject) root directory, stating with specific detail
what skills, knowledge, and experience level, are required before
it is appropriate for someone examining the project to start work
on it. Include references to appropriate papers or tutorial and
background material. Include the actual material in a references/
directory tree if appropriate.

Also include contact details for advice when they get stuck. Try to
list departments or teams instead of specific people if possible.
People change roles much more quickly that the overall team or
department does.

This all seems reasonable. I would go a bit further and suggest
that this is largely what style guides _should_ provide. For
instance, see the Google C++ style guide, which is extremely
detailed: https://google.github.io/styleguide/cppguide.html
All engineers working in C++ at Google are expected to read and
internalize these rules, and a side-effect of the level of
detail expressed in them is that they do a reasonable job of
outlining the level of expertise expected of those programmers.

Similarly, see https://man.omnios.org/man7/style.7, which
describes in some detail the level of C proficiency expected for
working in a System V-based kernel.

Google also scatters "OWNERS" files throughout the monorepo;
this is mainly for the vectoring code reviews (a review from an
OWNER is required for integration), but also gives a good
pointer to a team of folks who can help with any given project.

There was a companion "C++ primer" document that Google
published internally for C++ programmers, but I don't know
whether that was published externally; I can't find a copy. It
was one of two places where I actually used troff in my time
working there.

So the way that I write software is likely to be far different
between projects/teams and across organizations. If I am
working on a project where excellence is the norm, then
parenthesizing every boolean expression is going to be tedious
and actually slow folks down; if I'm assuming all new-grads,
less so.

You could also state this initial target audience in the above document.

Agreed. Whatever convention one uses (whether a file in the
project itself, or some kind of external thing) documentation is
key.

PS: I'm actually serious about this. _You_, as the original team or
person to create a project, then get to set what is expected before
someone later on starts work on the project.

This stops that future person from having to guess what skills are
required and then finding out the hard way that they are in way over
their heads. It also avoids having to ask the questions you are
asking here.

I absolutely agree. I do think that style guides provide some
basis here, but those tend to be implicit. Explicit statements
can be very useful.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

- Dan C.

We program for requirements, but have to remember that another may have to work
on the code at some time in the future. Clarity should be very important. As for "experts", which can be nebulous, clarity never hurts.

I've noticed your preference over some time for "experts". You were doubtful of
my fondness for detailed comments in programs. "An expert should be able to understand code." Well, there is no such thing as an "expert" that never misunderstands some complex code. "WTINSTAAETNMSCC" :-)

But even if there was, what does such do to productivity? Nothing good, I'd think.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <109cajs$1rfur$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 8/29/2025 9:11 AM, Dan Cross wrote:

In article <108k9de$1f69$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

And _this_ is an example of why Simon's policy of backets around
everything makes it explicitly clear what was intended. :-)

*At some expense for expert users.

Which again, comes back to what I think is _actually_ the
interesting question: who do we write these programs for?

We program for requirements, but have to remember that another may have to work
on the code at some time in the future. Clarity should be very important. As
for "experts", which can be nebulous, clarity never hurts.

This is the point I keep trying to make, but evidently keep
failing at: what is clear for one person may not be clear for
another. Something that is cryptically unclear for a novice in
a particular language, say, may be perfectly clear to an
experienced practioner. Similarly, something that feels very
clear to a novice may feel needlessly verbose and clunky, and
thus unclear, for someone with more experience. I pointed out
that this varies across projects, and that to usefully
contribute to some things, one really does need a certain level
of expertise.

I've noticed your preference over some time for "experts".

Ooo, I should qualify that, then. I don't have a preference for
"experts" so much as a bias towards developing expertise; I want
very much to bring new engineers into projects and provide them
with the tools and guidance to ramp up their skills until they
become go-to resources. To me, in part, that means becoming
expert with their tools, be that some sort of interactive
environment (a particular operating system and its idioms, text
editor, revision control system, what have you) and the
technologies that they work with, including programming
languages.

Recall that the genesis of this subthread had to do with
understanding whether any given language provides
short-circuiting for boolean expressions; opinions on this
matter varied, though I find myself falling into the camp of,
"yes, you really ought to know this; it's usually so common
that it becomes idiom." In particular, advocating avoiding
idiomatic use of the language because it _may_ be unclear to
someone unfamiliar with that language feels like it's erring
too far on the side of biasing against expertise.

You were doubtful of my fondness for detailed comments in
programs.

I believe you are referring to a thread from May, 2024;
something about xterm that inevitably drifted, and where you
posted a bit of code to do something with sockets to which I
responded with some critique. https://rbnsn.com/pipermail/info-vax_rbnsn.com/2024-May/148149.html

If so, then I disagree with the above characterization: it was
not that I was doubtful of detailed comments, but rather, that
I found the comments in the snippet of code that you posted
inadequate and largely superflous (ie. simply parroting the
code), and in a number of cases inaccurate and/or misleading.

My attitude on comments may be best illustrated by the example
I wrote up in my response to the John Ousterhout/Robert Martin
"debate" a few months ago. My writeup: https://github.com/dancrossnyc/literateprimes; see Primes.java
for an example of my preferred commenting style.

To sum it up: I value information density. If something can be
communicated, clearly and understandable, with fewer words and
random glyphs in a comment, then in my opinion, that is better.

"An expert should be able to understand code."

Well, this is true. But that doesn't mean that a programming
expert is necessarily going to be able to understand the domain,
and that's where comments _really_ shine: they are best when
they explain the why rather than the how. Occasionally the
implementation is sufficiently complex and/or subtle that it
deserves a comment, but that's pretty rare.

But I think it was Arne who said something like that.

Well, there is no such thing as an "expert" that never
misunderstands some complex code. "WTINSTAAETNMSCC" :-)

Of course! This happens all the time. Again: I didn't say
comments aren't useful. Indeed, my last line in the message at https://rbnsn.com/pipermail/info-vax_rbnsn.com/2024-May/148128.html
was:

"I agree that well-commented code is useful."

But even if there was, what does such do to productivity? Nothing good, I'd think.

I'd argue that drawing a bunch of little boxes around things
doesn't really do much for productivity, either, but YMMV.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/2/2025 9:35 AM, Dan Cross wrote:

In article <10943ve$3r9go$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

This is all true. I think one might paraphrase this as meaning
that you write code for the programmer that is slightly below
the median, and only hire engineers at median level or higher.

But this is slightly different than what I meant, which might be
similarly reframed as asking, how does one figure out what
"median" means? What is the base level of competence one might
assume when working on any given project/codebase/etc?

For instance, this demonstrably differs between organizations; I
would argue it often varies across projects within an
organization as well, and probably even within a project as the
project evolves over time. So how does one calibrate the median
point to which one targets ones programming standards, and how
does one ensure that it remains applicable?

You could always create a "!!!Change_Skills_Required.README" in the
project (or subproject) root directory, stating with specific detail
what skills, knowledge, and experience level, are required before
it is appropriate for someone examining the project to start work
on it. Include references to appropriate papers or tutorial and
background material. Include the actual material in a references/
directory tree if appropriate.

Also include contact details for advice when they get stuck. Try to
list departments or teams instead of specific people if possible.
People change roles much more quickly that the overall team or
department does.

This all seems reasonable.

Horrible idea.

It works fine as long as original team is around and the language
used is still a main language in the company.

But a lot of software stay around for a very long time. 20 years,
30 years, 40 years.

Employees and skills does not.

Companies merge and spinoff. Developers get new jobs. Main
languages are changed.

And suddenly there is a need to make a fix or an enhancement in that
old program (which may still be making lot of money). And none from
the original team is around and the language is no longer a main
language so no real experts in that language around any more.

Some developer get assigned to do the fix/enhancement and start by
finding the "You need to be an expert in this language and if you
have questions ask A or B" file.

Depending on the personality it will end in:
* laughing
* crying
* cursing
* writing to TheDailyWtf

Useless.

There is an old joke with a very good point:

"Always code as if the guy who will maintain your code is a violent
psychopath who knows where you live"

I would go a bit further and suggest
that this is largely what style guides _should_ provide. For
instance, see the Google C++ style guide, which is extremely
detailed: https://google.github.io/styleguide/cppguide.html
All engineers working in C++ at Google are expected to read and
internalize these rules, and a side-effect of the level of
detail expressed in them is that they do a reasonable job of
outlining the level of expertise expected of those programmers.

That works great in current situation.

But what if Google sell the product in 15 years due to some
corporate restructuring. The buying company will not adopt
that guide.

What if Google in 20 years decode to drop C++ as a main
language and drop the guide. Maybe not likely with that
company and that language, but in general companies change
preferred languages occasionally.

Google also scatters "OWNERS" files throughout the monorepo;
this is mainly for the vectoring code reviews (a review from an
OWNER is required for integration), but also gives a good
pointer to a team of folks who can help with any given project.

Now. How many of them will be in the company in 25 years and
still remember anything?

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 10:33 PM, Dan Cross wrote:

In article <68b2549f$0$718$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

Which is why I always preferred working for people with well defined
local coding (and comment) standards. And, yes, I have worked for both. >>>

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

Yes.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

It does not take that much to get coding conventions
followed.

Statements like this beg the question, what is the largest
project you have worked on, and with how many other engineers?
I am asking sincerely, by the way; that's not a dig.

I once worked in a, at the time, 2BLOC monorepo with ca O(10^5)
programmers working in it concurrently in ~20 engineering
offices spread across the globe.

Some small some big.

Not quite as big as that though.

But the important question is not the size of the org.

The important question is the commitment of senior management
to enforce governance.

If that commitment is there, then it is matter of basic
management skills to get it implemented.

Mgr->Dev

or:

EVP->SVP->VP->SrDir->Dir->PriMgr->SrMgr->Mgr->Dev

A tiny subproject within that was ~1MLOC split between about 500
KLOC in C++, and the other 500 KLOC in Common Lisp; HC was
around 20 FTEs mostly in a single office.

The local style guide mandated that the maximum line lenth in
Lisp was 100 characters; I counted and estimated that at least
20% of lines had more than 110 characters.

That project came through an acquisition, and the code was
inherited. On the other hand, the rest of the organization had
_very_ rigorous code style rules for various languages (five
officially supported languages, and a dozen or so other,
unofficially supported languages) and gated integration
verifying compliance with those rules through both review and
automatic tooling. In that code base, style violations were
exceedingly rare.

But this is the difference between making something a strong
part of the organization's cultural norms and supporting it with
tooling and just wishing the problem away.

Wishing does not solve anything.

But leadership does.

The CTO want the standard followed.

All supervisors get a goal in their MBO/WG/whatever
to implement review minimum X% of code, ticket
deviations and ensure they get fixed.

Then do it. Nobody will want to mess up their bonus/raise/promotion/stackranking/whatever
for that.

Developers get the stuff reviewed. They get a ticket
to fix it in that code and other code. After one or
two times they make sure that there is no deviations -
easier to just do it right the first time than to
have to do it later.

If >5% of code is reviewed and not following coding
convention get flagged and the guilty get asked to fix
the code *and* other code that has same problem, then
in a few months everyone is following. The risk of
non compliance eventually being detected and the hassle
of doing the fixes makes it easier to do the right
thing the first time.

That's cute, until managers step in and tell you to igore all of
that, because they've got a customer breathing down their neck
to get a feature they need into production. It also shows a
distinct lack of respect for your engineers.

Those tickets just get handled similar to any other tickets
not making it for the release.

They go into the todo-list/backlog/whatever.

Totally standard process.

The point is that you really need to inculctate respect for the
value that comes from rigorous adherence to those rules, and
support it with tooling so that they are easy to comply with
(and there are meaningful consequences for igoring them---like
your change just can't be submitted). Otherwise, they will just
be ignored, and attempts to force them by making people do a
bunch of grunt work if they're caught violating one will
backfire.

The "culture of fear" approach that you and Bill both seem to be
advocating simply does not scale, especially once it runs
headlong into the reality of the business considerations that
come with taking engineer time to do a bunch of busy work to
fix something that somebody else did.

It is how businesses work.

Developers are free to use whatever standard or lack
of standard in their hobby projects.

At work they do whatever the company want, because the
company is paying them to do that.

It is the only approach that scale.

Having everyone do what they believe is right does
not scale.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 6 Sep 2025 19:09:50 -0000 (UTC), Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

* Wirth Pascal did not have it (conformant array)

AFAIK Wirth Pascal had it.

ItrCOs not in Jensen & Wirth (1973). Formal parameter types can only be
rCLtype identifierrCY.

<https://web.archive.org/web/20151106112334/http://www.pascal-central.com/standards.html>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <109fr04$2n3qp$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:33 PM, Dan Cross wrote:

In article <68b2549f$0$718$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 9:24 AM, Dan Cross wrote:

In article <mhdnkaF9t36U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

Which is why I always preferred working for people with well defined >>>>> local coding (and comment) standards. And, yes, I have worked for both. >>>>

Yup, though this doesn't _really_ address the question.

But yes: having a locally agreed upon style for such things is a
_huge_ boon for maintainability, particularly across a large
codebase. Sure, it's fun to belly up to the virtual bar and
debate the relative merits of different styles on USENET,
complete with contrived examples for or against different
conventions. But the reality is that if one is consistent
within a code base, it doesn't really matter all that much;
competent programmers will absorb the rules in a matter of days
or weeks.

Yes.

The issue is that someone has to define the style and then
mandate its use, and it has to be enforced through rigorous
review and automated tooling. Given a sufficiently large group
of users, not everyone is going to agree with every rule; the
trick is in getting them to follow those rules regardless.

It does not take that much to get coding conventions
followed.

Statements like this beg the question, what is the largest
project you have worked on, and with how many other engineers?
I am asking sincerely, by the way; that's not a dig.

I once worked in a, at the time, 2BLOC monorepo with ca O(10^5)
programmers working in it concurrently in ~20 engineering
offices spread across the globe.

Some small some big.

Not quite as big as that though.

That's very vague.

But the important question is not the size of the org.

The important question is the commitment of senior management
to enforce governance.

You're saying something close to what I am, which as a reminder
that this is really predicated on the organizational culture and
automation. But you seem intent to focus on this "senior
management" thing as the only thing that matters while making
vague assertions that it is "easy" as a result. It is not. It
is _hard work_ to build an engineering culture that makes this a
core value.

A tiny subproject within that was ~1MLOC split between about 500
KLOC in C++, and the other 500 KLOC in Common Lisp; HC was
around 20 FTEs mostly in a single office.

The local style guide mandated that the maximum line lenth in
Lisp was 100 characters; I counted and estimated that at least
20% of lines had more than 110 characters.

That project came through an acquisition, and the code was
inherited. On the other hand, the rest of the organization had
_very_ rigorous code style rules for various languages (five
officially supported languages, and a dozen or so other,
unofficially supported languages) and gated integration
verifying compliance with those rules through both review and
automatic tooling. In that code base, style violations were
exceedingly rare.

But this is the difference between making something a strong
part of the organization's cultural norms and supporting it with
tooling and just wishing the problem away.

Wishing does not solve anything.

No one said that it does. You'll note I said that it requires
enculturation and automation to do at scale. And it does.

But leadership does.

...and tooling. And culture. All of which can flow from
leadership, but in Google's case it came from the ground up, and
on multiple fronts. The style guides, and then for example unit
testing, which was absolutely grass-roots driven by engineers.
There was even an internal group called the "test mercenaries"
that went around working with other teams, teaching them how to
leveral unit tests, building internal CI frameworks that worked
with Google's monorepo and build system, etc.

The CTO want the standard followed.

All stick no carrot? Wrong.

All supervisors get a goal in their MBO/WG/whatever
to implement review minimum X% of code, ticket
deviations and ensure they get fixed.

Then do it. Nobody will want to mess up their >bonus/raise/promotion/stackranking/whatever
for that.

Developers get the stuff reviewed. They get a ticket
to fix it in that code and other code. After one or
two times they make sure that there is no deviations -
easier to just do it right the first time than to
have to do it later.

Name one organization where you've seen that happen. Give a
real world example.

If >5% of code is reviewed and not following coding
convention get flagged and the guilty get asked to fix
the code *and* other code that has same problem, then
in a few months everyone is following. The risk of
non compliance eventually being detected and the hassle
of doing the fixes makes it easier to do the right
thing the first time.

That's cute, until managers step in and tell you to igore all of
that, because they've got a customer breathing down their neck
to get a feature they need into production. It also shows a
distinct lack of respect for your engineers.

Those tickets just get handled similar to any other tickets
not making it for the release.

They go into the todo-list/backlog/whatever.

Totally standard process.

Or you provide an automated tool that people can configure to
work with common editors so that their code is automatically
formatted on save, and then you build that into the CI process
so that violations are flagged on review, and you gate
integration on resolving this problems _at review time_.

THAT is a totally standard process.

The point is that you really need to inculctate respect for the
value that comes from rigorous adherence to those rules, and
support it with tooling so that they are easy to comply with
(and there are meaningful consequences for igoring them---like
your change just can't be submitted). Otherwise, they will just
be ignored, and attempts to force them by making people do a
bunch of grunt work if they're caught violating one will
backfire.

The "culture of fear" approach that you and Bill both seem to be
advocating simply does not scale, especially once it runs
headlong into the reality of the business considerations that
come with taking engineer time to do a bunch of busy work to
fix something that somebody else did.

It is how businesses work.

Not really. Perhaps the business you've worked in, but if so,
they were rather poorly run.

Developers are free to use whatever standard or lack
of standard in their hobby projects.

At work they do whatever the company want, because the
company is paying them to do that.

It is the only approach that scale.

Empirical evidence suggests otherwise.

Having everyone do what they believe is right does
not scale.

No one said that. You're arguing a strawman.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <68bb6904$0$710$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/2/2025 9:35 AM, Dan Cross wrote:

In article <10943ve$3r9go$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

This is all true. I think one might paraphrase this as meaning
that you write code for the programmer that is slightly below
the median, and only hire engineers at median level or higher.

But this is slightly different than what I meant, which might be
similarly reframed as asking, how does one figure out what
"median" means? What is the base level of competence one might
assume when working on any given project/codebase/etc?

For instance, this demonstrably differs between organizations; I
would argue it often varies across projects within an
organization as well, and probably even within a project as the
project evolves over time. So how does one calibrate the median
point to which one targets ones programming standards, and how
does one ensure that it remains applicable?

You could always create a "!!!Change_Skills_Required.README" in the
project (or subproject) root directory, stating with specific detail
what skills, knowledge, and experience level, are required before
it is appropriate for someone examining the project to start work
on it. Include references to appropriate papers or tutorial and
background material. Include the actual material in a references/
directory tree if appropriate.

Also include contact details for advice when they get stuck. Try to
list departments or teams instead of specific people if possible.
People change roles much more quickly that the overall team or
department does.

This all seems reasonable.

Horrible idea.

Style guides and documentation are a horrible idea?

It works fine as long as original team is around and the language
used is still a main language in the company.

But a lot of software stay around for a very long time. 20 years,
30 years, 40 years.

Employees and skills does not.

Companies merge and spinoff. Developers get new jobs. Main
languages are changed.

That's all orthogonal to Simon's suggestion.

And suddenly there is a need to make a fix or an enhancement in that
old program (which may still be making lot of money). And none from
the original team is around and the language is no longer a main
language so no real experts in that language around any more.

Yes, so that's why you document and have standards.

Some developer get assigned to do the fix/enhancement and start by
finding the "You need to be an expert in this language and if you
have questions ask A or B" file.

A or B is a team or project. References are available for
languages. Something that outlines the expectations seems
reasonable to me.

Depending on the personality it will end in:
* laughing
* crying
* cursing
* writing to TheDailyWtf

Useless.

What are you talking about? Did you even read what you're
responding to?

There is an old joke with a very good point:

"Always code as if the guy who will maintain your code is a violent >psychopath who knows where you live"

Well then, I'd better try to keep him happy by writing code that
is consistent with the local style and documenting how to
approach the code base.

I would go a bit further and suggest
that this is largely what style guides _should_ provide. For
instance, see the Google C++ style guide, which is extremely
detailed: https://google.github.io/styleguide/cppguide.html
All engineers working in C++ at Google are expected to read and
internalize these rules, and a side-effect of the level of
detail expressed in them is that they do a reasonable job of
outlining the level of expertise expected of those programmers.

That works great in current situation.

But what if Google sell the product in 15 years due to some
corporate restructuring. The buying company will not adopt
that guide.

Wow. Have you ever actually worked on a project that was
acquired from some organization? You really think they throw
out all the documentation and just start doing their own thing
on a >>1MLOC code base?

What if Google in 20 years decode to drop C++ as a main
language and drop the guide. Maybe not likely with that
company and that language, but in general companies change
preferred languages occasionally.

Now we're back to "what ifs" and the associated risks that you
were so quick to dismiss in another thread. Bluntly: much as
Google _would_ actually like to dump C++, what you are
describing just isn't going to happen.

What happened to all the senior management mandates that you
said made this problem so easy?

Google also scatters "OWNERS" files throughout the monorepo;
this is mainly for the vectoring code reviews (a review from an
OWNER is required for integration), but also gives a good
pointer to a team of folks who can help with any given project.

Now. How many of them will be in the company in 25 years and
still remember anything?

OWNERS files were maintained via automated crawlers that made
sure they were up to date; if an OWNERS file became empty, the
issue was escalated to the OWNERS of the enclosing project.
Eventually you are at the root of the monorepo.

It's amazing how automation and a strong engineering culture can
address these strawman concerns.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Mo 25 Aug 2025 at 02:34, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 23 Aug 2025 23:49:14 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Sat, 23 Aug 2025 19:45:19 -0400, Arne Vajh|+j wrote:

1) VMS Basic using = for both assignment and equal comparison,
while most other languages use different symbols (= and ==,
:= and =, = and .eq., ...)

But they only apply to non VMS Basic developers.

Nearly all BASICs were like that, including I think Microsoft BASIC.

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

You can do rhe same in Common Lisp and various schemes.

'Andreas
--
ceterum censeo redmondinem esse delendam
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 27 Sep 2025 20:12:37 +0200, Andreas Eder wrote:

On Mo 25 Aug 2025 at 02:34, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

One trick they missed was allowing interval comparisons like this:

if "0" <= ch <= "9" or "a" <= ch <= "f" or "A" <= ch <= "F" :

I think only Python has that.

You can do rhe same in Common Lisp and various schemes.

But none of those languages have infix operators.

Remember, this is purely a syntactic thing handled in the Python
compiler: when you implement the underlying rCL__le__rCY and other methods <https://docs.python.org/3/reference/datamodel.html#object.__lt__> for
your type, you only define them as taking two operands, and Python
does the rest.
--- Synchronet 3.21a-Linux NewsLink 1.2