Re: Which code style do you prefer the most?

On 26.02.2025 21:09, David Brown wrote:

On 26/02/2025 17:47, Janis Papanagnou wrote:

On 26.02.2025 17:26, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:
>

It is also an argument against writing code like :
>
    if (flag)
        doThis();
>
Not only is adding a "doThat();" error-prone in itself (forgetting to
add braces is a real risk), but it means adding (or later removing) a
single line is now a three-line change.

>
Agreed.

>
I consider that argument of about the same quality as the suggestion
to write
>
   if (42 == a)    instead of     if (a == 42)
>
just to prevent the error of writing    if (a = 42)    in "C" (and
similar languages).
>
I don't think this is convincing.

 
The difference is that the mistake :
 
    if (flag)
        doThis();
        doThat();
 
really does happen in actual released code, and has caused significant
problems.

Yes, only that there is no _*principle* difference_ compared to
  if (a = 42)
that "really does happen in actual released code, and has caused
significant problems".

And if you have mixed tabs and spaces in the code, it is
entirely possible that with different editors with different tab sizes,
the code appears differently - adding to the confusion and the
likelihood of errors going unnoticed.
 
Mistakes like "if (a = 42)" rarely make it past initial testing, and
most compilers have warned about such errors for decades.  (Some
compiles - including modern gcc and clang - can spot the confusing
indentation.  But that has not been the case for so long.)

I cannot confirm what you say. Both sorts of errors *can* be caught
during project review or test phases of "actually released code".

In the contexts I worked in both types of errors were actually made,
the assignment-error actually even more often. And a whole function
('doThat();') that is wrongly executed unconditionally gets quickly
detected, in my experience. - YMMV.

What I wanted to say is that language syntaxes have pitfalls where
you need knowledge and experience. Often _wrong ways_ are chosen to
counter the language (mis-)design. At some point, when the compiler
vendors hear about such problems, they support detection of such
issues (usually with some compile switch activated). But the problem
of 'if(a=42)' is not solved by always *thinking* to instead write it
as 'if(42=a)' (erm, 'if(42==a)'). Since if you anyway _think_ about
that then you can then as well just write 'if(a==42)'. And of course
it also doesn't address the general case in the first place. Whether
'if(a=b)' is correct isn't fixed by getting used to write 'if(b=a)'.

It's similar to with the control constructs without spurious braces.

Teach your programmers to use (in "C"-like languages) '==' if they
intend to compare things, teach them to add braces when collecting
more than one statement in some control construct or block.

Beyond that it's IMO just opinion and preferences.

Janis