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