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
