search for: braced

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...

...ists.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...

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

On 6/23/20 9:39 AM, Robinson, Paul via llvm-dev wrote: > >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jay Foad via >> llvm-dev >> Sent: Tuesday, June 23, 2020 4:47 AM >> To: Mehdi AMINI <joker.eph at gmail.com> >> Cc: llvm-dev at lists.llvm.org; Matt Arsenault <arsenm2 at gmail.com>

I'm with Matt on this one. I much prefer the approach of ALWAYS use braces for ifs and for loops, even if they're not needed, for basically the same reasons as he put. The number of times I've added a statement inside an if without braces and forget to add them is annoyingly high, especially as it's not always an obvious error upfront. Similarly, being involved in a downstream

Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> writes: > I think braces should be added in all contexts, and the more contexts > the better. It eliminates any inconsistency or attempt to contextually > interpret rules. It also reduces merge conflicts, since something > eventually something will probably be added inside any control flow > statement. I’ve suffered

...ists.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...

...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 prefe...

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). For example: BAD: if (cond) // Comment foo(); GOOD: if (cond) { // Comment foo(); } BAD: if (cond) { foo(); // Comment } GOOD: if (cond) foo(); // Comment BAD: if (cond) for(;;) foo() GOOD: if (cond)

At the very least, I accept clarifying the wording to make it clear where braces should/shouldn't be used. I personally would still prefer a general "always add braces in new code" rule, given that I literally just ran into another case where a code change I made locally caused test failures because I'd forgotten to add the braces on a previously single-line if, although in this

Personally, I favor "always use braces" because it helps readability for me. The compiler may be good at flagging misleading indentation, but my visual processing system is terrible at it, especially since we use a measly two spaces for indentation. And we grant indentation exceptions for--among other things--case labels in switches. When some nested statements have braces and others

Hi all- A few weeks ago I noticed that our "omit braces with single line blocks" rule wasn't written down! Additionally, as a group on IRC and in review, noticed that the enforcement of this rule has been extremely inconsistent. We made a first run at codifying our existing practice here: https://reviews.llvm.org/D80947, which was then committed after significant time on

Hi paulr: Thanks for your kindly response. Maybe I don't describe my question cleanly, let me show more information. From my side, I notice that whether we are in the continue keyword mode or we are in the right brace mode, the target of br instruction is the same, i.e. for loop Continue Keyword Mode: ; <label>:6: ; preds = %3 br label

Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes: > For those who don’t like it, is the currently documented policy broken > enough to be important to changing? I believe it is, simply for safety reasons. Adding a statement to a single-statement block can introduce bugs. Mandating braces everywhere prevents that. > I assume you wouldn’t recommend a massive rewrite

If we had a very naïve way of generating IR, in the 'continue' case you would actually see TWO branch instructions: one to implement the 'continue' statement, and one as part of the control flow of the 'for' loop. The branch for the 'continue' statement would have the source location of the 'continue' and the branch for the control-flow of the 'for'

Re: placement of braces and "else" clauses. At the R prompt, I believe their placement must avoid causing a syntactically complete statement at the wrong place. This can results in what might be considered rather awkward looking code. IF it is known that code will be used via sourcing a script only, is there any potential problem with placing braces as shown below ? xxx <-

Let me show you the following simple C code: int main() { int i; for (i = 0; i < 256; i++) { i++; } } In this simple C code, if we use Clang to compile it and debug it: We will get something like this: (gdb) b main Breakpoint 1 at 0x100000f7b: file a.c, line 5. (gdb) r Starting program: a.out [New Thread 0x1403 of process 23435] warning: unhandled dyld version (15) Thread 2

As of r313998, this workflow no longer works: cd <build-dir> ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping I get: llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/lit.cfg.py:97: note: using clang: '/Volumes/Builds/llvm.org-coverage-braces-RA/bin/clang' llvm-lit:

Hello. Building R-patched from source on Win64 using current Rtools 3.5.0.4, I?m getting the following notes indicating an extra left brace somewhere; or is the problem on my end? My installed Perl is Strawberry 5.28.0.1-64 bit. Thank you, Avi (Sent from an iPhone, so my apologies if HTML also comes through) ------ Making HTML documentation ------ creating doc/manual/version.texi creating

Dear developers, while preparing to submit a package to CRAN, I noticed that a check for lost braces in Rd files (which is enabled in the current r-devel when checking with the '--as-cran' option) seems to return false positives. More specifically, a 'Lost braces' NOTE is issued (at least sometimes) when using the \insertRef{...}{...} command from the Rdpack package. Since