[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

[Matthew Knepley]

On Tue, Jan 22, 2013 at 2:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Tue, Jan 22, 2013 at 1:28 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>
>> Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem
>> anyway, it's 'just another line'.
>>
>
> Yeah, well, I still think it's rude for a build script to mess with the
> user's private repository configuration. We only get away with it because
> beginners don't know better and experts usually configure their system so
> it doesn't run (e.g., by pulling BuildSystem themselves) or know that it's
> running.
>
>
>>
>> If we reject the commit server-side, the author will
>>
>>> have to edit their history (requires enabling an extension unless it's
>>> the last commit). Since it's a hassle to go back and fix the history,
>>> hopefully it will teach developers to enable the commit hooks.
>>>
>>
>> Eventually we can come up with a hook that aggregates multiple commits,
>> i.e. the user only needs to add a follow-up commit fixing the violation
>> rather than fiddling with the history.
>>
>
> This is horrible because the aggregating commit will touch lots of
> irrelevant lines. If it does more than change whitespace, git/hg can't even
> give us a diff that looks past that rearrangement. It's important for every
> commit making it into the repository to be formatted consistently.
>
>
>>        -> Configure uncrustify such that it reports violations (nightly)
>>>       -> Document user-specific uncrustify configs
>>>
>>>
>>> Until someone finds a way to do this with Hg, I think this last point
>>> would only be meaningful to git users.
>>>
>>
>> Albeit not ideal, I think it's reasonable to
>>  - either wait for a similar way of doing that with Mercurial, or
>>  - use gitifyhg
>> for users who insist on using custom non-PETSc-style. This is a fairly
>> low hurdle compared to what you get for it.
>>
>
> Queue Matt screaming about how he'll never (a) use git OR (b) put a space
> after 'for'.
>

I am not morally opposed to git (spaces after for is as attractive as crack
on the repairman). However,
we will not be using git for PETSc before my daughter goes to school.

   Matt

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130122/892cbdc2/attachment.html>