[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?
Barry Smith
bsmith at mcs.anl.gov
Mon Jan 21 21:43:59 CST 2013
On Jan 21, 2013, at 7:53 PM, Matthew Knepley <knepley at gmail.com> wrote:
> On Mon, Jan 21, 2013 at 7:23 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> Hi,
>
>
>
> Things like
>
> if (y < 12) {ierr = Something(); CHKERRQ(ierr);}
>
> don't match the standard but …. am I being too picky? I believe
> the PETSc make uncrustify rule would move that to separate lines.
>
>
> I expect that it's a lot easier to define a rule where '{' opens a
> new block on the next line rather than having a 'sometimes it's a
> single line'-type of exception.
>
>
> Yes, though
>
> if (y < 12) {
> ierr = Something();CHKERRQ(ierr);
> }
>
> takes three times as many lines. I don't care much either way, but it's
> nice to not waste vertical space.
>
> But, unfortunately, it is also a good example of why uncrustify-like tools have a hard time with PETSc:
>
>
> if (y < 12) {
> ierr = Something();
> call_other_function(ierr);
> }
>
> is semantically very much the same to a parser, yet it should lead to different formatting.
>
> Its my belief that tools are there to help us do the things we want to do, not to determine what we do.
I agree, but on the other hand I use compilers instead of writing my own assembler code (etc etc etc) because the compiler tools are "good enough" even though they do force some things on me I don't like. So here the question is: can we find/fix tools to be "good enough" to be worth using, even though they sometimes force us to do things we don't exactly like.
Barry
>
> Matt
>
> Best regards,
> Karli
>
> --
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
More information about the petsc-dev
mailing list