Me? I would modify the first sentence from:> When writing the body of an if, else, or loop statement, > omit the braces to avoid unnecessary line noise. However, > braces should be used in cases where the omission of braces > harm the readability and maintainability of the code.To be:> Braces are optional around the body of an if, else, or loop statement, > except in cases where the omission of braces harm the readability and > maintainability of the code.Followed by the rest of the section that describes cases where readability or maintainability would be harmed. And then be done with it. - Steve On 6/22/20, 1:44 PM, "Chris Lattner" <clattner at nondot.org> wrote: External email: Use caution opening links or attachments For those who don’t like it, is the currently documented policy broken enough to be important to changing? I assume you wouldn’t recommend a massive rewrite of the codebase, so we’re going to be with this for quite some time. -Chris > On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Did this conversation reach a conclusion? > > My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. > > The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. > > I didn't register any technical arguments for less-than-fully-braced statement -- the preference seemed to be aesthetic. I may have missed a technical argument. > > Certainly an "always use braces" rule would be simpler than what's documented now in the LLVM Coding Standards [1]. > > Another option would be to make braces a developer's choice, and ask that those omitting braces please follow the rules documented in [1]. > > [1] https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements > > On 6/18/20, 3:56 AM, "llvm-dev on behalf of Nicolai Hähnle via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: > > External email: Use caution opening links or attachments > > > On Tue, Jun 16, 2020 at 10:35 AM Momchil Velikov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> My 2 pennies is braces add unnecessary clutter and impair readability when >> used on a *single-line* statement. I count comments, that are on their >> own line as statement(s). > > +1 for this. I think braces around single-line statements can be > allowed, but they really shouldn't be mandated, and that's been my > personal policy for reviews. In particular, > > if (!is_transform_applicable) { > return {}; > } > > is very aggravating clutter. > > Braces should be required around multi-line statements. Note: > > BAD: > for (...) > for (...) > single_line_statement; > > GOOD: > for (...) { > for (...) > single_line_statement; > } > > Cheers, > Nicolai > -- > Lerne, wie die Welt wirklich ist, > aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Me? I would modify the first sentence from: > > > When writing the body of an if, else, or loop statement, > > omit the braces to avoid unnecessary line noise. However, > > braces should be used in cases where the omission of braces > > harm the readability and maintainability of the code. > > To be: > > > Braces are optional around the body of an if, else, or loop statement, > > except in cases where the omission of braces harm the readability and > > maintainability of the code. >The current wording is more clear as it expresses unambiguously the preferred way of formatting the code. I don't see a benefit to this change of phrasing (on the opposite, I prefer less ambiguous). -- Mehdi> > Followed by the rest of the section that describes cases where readability > or maintainability would be harmed. > > And then be done with it. > > - Steve > > On 6/22/20, 1:44 PM, "Chris Lattner" <clattner at nondot.org> wrote: > > External email: Use caution opening links or attachments > > > For those who don’t like it, is the currently documented policy broken > enough to be important to changing? > > I assume you wouldn’t recommend a massive rewrite of the codebase, so > we’re going to be with this for quite some time. > > -Chris > > > On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Did this conversation reach a conclusion? > > > > My ad hoc tally says that a slight majority of the responders > preferred to fully brace statements and no one wanted to totally eliminate > braces. > > > > The technical arguments for fully braced statements were 1) it's > considered a slightly safer coding style and 2) commit diffs with fully > braced statements may be slightly more to the point. > > > > I didn't register any technical arguments for less-than-fully-braced > statement -- the preference seemed to be aesthetic. I may have missed a > technical argument. > > > > Certainly an "always use braces" rule would be simpler than what's > documented now in the LLVM Coding Standards [1]. > > > > Another option would be to make braces a developer's choice, and ask > that those omitting braces please follow the rules documented in [1]. > > > > [1] > https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements > > > > On 6/18/20, 3:56 AM, "llvm-dev on behalf of Nicolai Hähnle via > llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of > llvm-dev at lists.llvm.org> wrote: > > > > External email: Use caution opening links or attachments > > > > > > On Tue, Jun 16, 2020 at 10:35 AM Momchil Velikov via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> My 2 pennies is braces add unnecessary clutter and impair > readability when > >> used on a *single-line* statement. I count comments, that are on > their > >> own line as statement(s). > > > > +1 for this. I think braces around single-line statements can be > > allowed, but they really shouldn't be mandated, and that's been my > > personal policy for reviews. In particular, > > > > if (!is_transform_applicable) { > > return {}; > > } > > > > is very aggravating clutter. > > > > Braces should be required around multi-line statements. Note: > > > > BAD: > > for (...) > > for (...) > > single_line_statement; > > > > GOOD: > > for (...) { > > for (...) > > single_line_statement; > > } > > > > Cheers, > > Nicolai > > -- > > Lerne, wie die Welt wirklich ist, > > aber vergiss niemals, wie sie sein sollte. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/de85a2e1/attachment-0001.html>
On Mon, Jun 22, 2020 at 7:32 PM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary line noise. However, >> > braces should be used in cases where the omission of braces >> > harm the readability and maintainability of the code. >> >> To be: >> >> > Braces are optional around the body of an if, else, or loop statement, >> > except in cases where the omission of braces harm the readability and >> > maintainability of the code. >> > > The current wording is more clear as it expresses unambiguously the > preferred way of formatting the code. I don't see a benefit to this change > of phrasing (on the opposite, I prefer less ambiguous). > >I'm going to agree with Mehdi here. -eric> -- > Mehdi > > >> >> Followed by the rest of the section that describes cases where >> readability or maintainability would be harmed. >> >> And then be done with it. >> >> - Steve >> >> On 6/22/20, 1:44 PM, "Chris Lattner" <clattner at nondot.org> wrote: >> >> External email: Use caution opening links or attachments >> >> >> For those who don’t like it, is the currently documented policy >> broken enough to be important to changing? >> >> I assume you wouldn’t recommend a massive rewrite of the codebase, so >> we’re going to be with this for quite some time. >> >> -Chris >> >> > On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > >> > Did this conversation reach a conclusion? >> > >> > My ad hoc tally says that a slight majority of the responders >> preferred to fully brace statements and no one wanted to totally eliminate >> braces. >> > >> > The technical arguments for fully braced statements were 1) it's >> considered a slightly safer coding style and 2) commit diffs with fully >> braced statements may be slightly more to the point. >> > >> > I didn't register any technical arguments for >> less-than-fully-braced statement -- the preference seemed to be aesthetic. >> I may have missed a technical argument. >> > >> > Certainly an "always use braces" rule would be simpler than what's >> documented now in the LLVM Coding Standards [1]. >> > >> > Another option would be to make braces a developer's choice, and >> ask that those omitting braces please follow the rules documented in [1]. >> > >> > [1] >> https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements >> > >> > On 6/18/20, 3:56 AM, "llvm-dev on behalf of Nicolai Hähnle via >> llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of >> llvm-dev at lists.llvm.org> wrote: >> > >> > External email: Use caution opening links or attachments >> > >> > >> > On Tue, Jun 16, 2020 at 10:35 AM Momchil Velikov via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: >> >> My 2 pennies is braces add unnecessary clutter and impair >> readability when >> >> used on a *single-line* statement. I count comments, that are on >> their >> >> own line as statement(s). >> > >> > +1 for this. I think braces around single-line statements can be >> > allowed, but they really shouldn't be mandated, and that's been >> my >> > personal policy for reviews. In particular, >> > >> > if (!is_transform_applicable) { >> > return {}; >> > } >> > >> > is very aggravating clutter. >> > >> > Braces should be required around multi-line statements. Note: >> > >> > BAD: >> > for (...) >> > for (...) >> > single_line_statement; >> > >> > GOOD: >> > for (...) { >> > for (...) >> > single_line_statement; >> > } >> > >> > Cheers, >> > Nicolai >> > -- >> > Lerne, wie die Welt wirklich ist, >> > aber vergiss niemals, wie sie sein sollte. >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/9a8dedba/attachment.html>
On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary line noise. However, >> > braces should be used in cases where the omission of braces >> > harm the readability and maintainability of the code. >> >> To be: >> >> > Braces are optional around the body of an if, else, or loop statement, >> > except in cases where the omission of braces harm the readability and >> > maintainability of the code. > > > The current wording is more clear as it expresses unambiguously the preferred way of formatting the code. I don't see a benefit to this change of phrasing (on the opposite, I prefer less ambiguous).I really don't like the current wording. It reads like "Do X. However, don't do X if ..." (where X is omit braces). I do not find this unambiguous! And it makes me unsure how to interpret "to avoid unnecessary line noise: did it really mean "omit the braces /if/ that avoids unnecessary line noise"? Jay.
On Tue, Jun 23, 2020 at 4:30 AM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary line noise. However, >> > braces should be used in cases where the omission of braces >> > harm the readability and maintainability of the code. >> >> To be: >> >> > Braces are optional around the body of an if, else, or loop statement, >> > except in cases where the omission of braces harm the readability and >> > maintainability of the code. > > > The current wording is more clear as it expresses unambiguously the preferred way of formatting the code. I don't see a benefit to this change of phrasing (on the opposite, I prefer less ambiguous).The benefit of changing is, of course, that people don't actually agree that what's currently written down is a good idea. In other words, it is not clear that what is written down is actually the preferred way of formatting. I think what's written down today is good as "this is the minimum amount of braces that should be used". However, there are large parts of the code where braces are used in more places, using slightly different stylistic preferences, and where reviewers (including myself) suggest those additional braces. Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.