[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