[llvm-dev] Codifying our Brace rules-

[Mehdi AMINI via 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>