Re: Which code style do you prefer the most?

On 26/02/2025 14:06, Janis Papanagnou wrote:

On 26.02.2025 12:53, Ar Rakin wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

>
Re "goofy style"; I've seen someone preferring
>
   while (q(a,b))
       {
       a=b;
       f(x);
       if (c>d)
           {
           g(y);
           }
       }
>
To each his own.

>
That looks like a nightmare for the code reviewers.

I find that style grating.  But I don't think I'd call it a "nightmare" - I've seen far worse.
But from all my education and training in coding, mathematics, documentation, writing, and typography, I am a solid believer in one rule - the most important feature of any written information is the spacing.  If I were tasked with making that code clear, the first step would be to add a few spaces - "a = b;", "if (c > d)" - that would be higher priority than using a more "normal" brace style such as the "One True Brace Style".

 I cannot tell where that comes from; the person who uses it is an
experienced Perl programmer - may that be some convention in that
specific language context? (I can't tell.)
 WRT code reviews; in the past I had horrendous code that I needed
to reformat using a code-beautifier before I could review it. But
those were extreme (and only rare) cases. (And above yet isn't as
bad as those other artworks I had.)
 

I think it is more common in such cases to reject the code from the review, and insist that the author re-format it appropriately.  The reviewer's job is to /review/ the code, not fix it or clean it up.
One thing that is important for code reviewers, and any kind of comparisons between versions (such as for source code management systems), is to try to reduce the number of lines that are changed unnecessarily, and to try to make those changed lines clear.
This is a good reason for preferring // comments to /* */ comments - every line that is commented-out is clearly a commented-out line, and doesn't need the context.  (Ada - a language designed with an emphasis on making it harder to write incorrect or confusing code - does not have multi-line comments at all, partly for this reason.)
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.  If the braces are already in place, changes are more natural:
if (flag) {
doThis();
}
if (flag) {
doThis();
doThat();
}
You might not agree with that reasoning, or might not think it important enough to pick a style that requires such braces - but that's the kind of thing you should think about when determining the details of a style.   How does the style help make the code clearer?  How does it reduce the risks of errors when writing the code, or misunderstandings when reading the code?  How does that apply when doing different things with the code - reading it, writing it, reviewing it, changing it, copying it?