From: cross@spitfire.i.gajendra.net
In article ,
bill wrote:
>On 8/29/2025 9:11 AM, Dan Cross wrote:
>> In article <108k9de$1f69$1@dont-email.me>,
>> Simon Clubley wrote:
>>> On 2025-08-25, Arne Vajhøj 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.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
