Andrey Tarasevich writes:
> On 09/21/24 2:54 PM, Keith Thompson wrote:
>> One reason to "overuse" braces is that you can easily add another
>> statement. If you write:
>> if (failed)
>> WARN("failed because...");
>> else
>> ok++;
>> and later decide you need two statements in the else clause, you
>> then
>> need to add braces. If they're already there, you don't.
>
> Adding braces in this situation is _incomparably_ easier than
> splitting an annoying single-line `if` statement into multiple lines,
> discovered during an interactive debugging session. Which is something
> you yourself described as "easy enough" below.
Perhaps I don't use interactive debuggers as much as other programmers
do, but I certainly haven't found it terribly difficult to temporarily
reformat code as needed (not that I've run into that particular issue
very often). I'm likely to be modifying and rebuilding the software
anyway.
>> What you call "Egyptian" braces is the style used by the creators of the
>> language
>
> Firstly, this is style. Being a "creator of the language" does not
> make one an authority on code formatting style.
True.
> Secondly, most people pick up "the style used by the creators of the
> language" from the code samples used in the 2nd edition of K&R
> book. And, as we know, "the creators of the language" went a little
> lazy here. The samples were considered of "low importance" and fell
> victim to the tightening publishing schedules in front of the looming
> "threat" of the upcoming ANSI standard. The code samples were never
> properly updated to match the style and spirit of modern C.
You seem to be asserting that K&R-style brace placement goes against
"the style and spirit of modern C". In my opinion and experience, it
absolutely does not.
You prefer braces on their own lines. I prefer to put opening braces at
the end of the line. Neither of us is objectively right or wrong.
> This is BTW, the reason we have to deal with that pesky and atrocious
> manner to cast the result of `malloc` - another practice erroneously
> believed to be "the style used by the creators of the language".
>
>> and in a *lot* of open source software. Even if you don't like
>> the style, you'll need to deal with it.
>> I have my own fairly strong preferences about brace placement, but the
>> most important rule is to follow the conventions of the code I'm working
>> on.
>
> Certainly. It is not a good practice to force your own style onto
> someone else's code or an already existing code. Still, in most
> reasonably organized professional development environments personal
> preferences are normally welcomed with certain granularity. It is
> usually organized on "per translation unit" basis.
That's not my experience at all. In some environments, there's a
project-wide written coding standard (which may or may not be strictly
followed). In others, the style is (ideally) consistent at least across
each project or subproject.
I suppose I could deal with a project where each translation unit has
its own style, but thankfully I've never had to.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
|
|