Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: Re: how to make a macro work as a single line if stmt without braces Date: Sun, 22 Sep 2024 14:15:28 +0200 Organization: A noiseless patient Spider Lines: 86 Message-ID: References: <87frpsr7tf.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 22 Sep 2024 14:15:29 +0200 (CEST) Injection-Info: dont-email.me; posting-host="92d2f9b37acfcaeb5a5d0a5a62bab213"; logging-data="2319595"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18jk1dOyYtdS6ahRZuk6SIJoaDgbDZfmiQ=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:lOY9dswbDheMtyT+KLApaRYYGWY= Content-Language: en-GB In-Reply-To: Bytes: 4661 On 22/09/2024 05:05, Andrey Tarasevich wrote: > 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. I don't think "incomparably" is the word you are looking for - especially while making a comparison! Changes can always be made to code, and none of this is a particular challenge to do. > >> 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. > Agreed. > 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. > I can't speak for anyone else, but it is certainly not why I use this style. I have tried a few styles, I have seen many more, and it was a conscious decision about what I think makes code clearer to read and has the minimal risk of errors or misunderstandings. > 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". There are plenty of design decisions in C that some people will think were a good idea, and others think are a bad idea. Let's not go there! > >> 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. > Agreed. There's nothing worse than a git/subversion/whatever checkin when someone has changed the entire file to move around some braces or convert between their preferences of tabs or spaces.[1] > 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. > Practices vary somewhat. And while there's a fair variety of styles that can be seen as reasonable enough, it sometimes happens that the new person in a team has such a terrible style that they are forced to change. [1] Except, of course, a paper-cut. It's a well-established fact that there is nothing worse than a paper-cut!