[petsc-dev] I hate this one

[Matthew Knepley]

On Mon, Jan 21, 2013 at 5:59 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Matt,
>
>     Eventually I hope to get to a stage where the format in the repository
> is fixed but we have a tool (uncrustify is pretty good, but not perfect)
> that puts it in that form when committing/pushing? into the repository.
> This way you can have your uncrustify style that you use in your copy and
> only when it is committed/pushed? does it go into the standard format. This
> will make the tab-lovers, the else \n { lovers, the random weird spaces in
> some place lovers, etc all happy.  We could even consider just living with
> the limitations of uncrustify today, which would mean me dropping a few of
> my objections, …
>
>   Take a look at the uncrustify rule in conf/rules and its uncrustify
> configuration (that I constructed to match as much as possible what I think
> is best). There are uncrustify options for no space between for() etc that
> could perhaps be appropriately set to satisfy your coding style. I agree
> that trying to enforce a single 100% coding style on everyone is
> unnecessary but I do think that having a single style in the repository
> that can be automatically shifted around based on user is the right
> solution, we just are not there yet. Maybe with some group effort on
> uncrustify we can get there.
>

Okay, I will try and fix my clone to do this. When it works, I will post it.

   Matt


>    Barry
>
> I say committing/pushing? because I don't know what the exact mechanism
> would be to have consistent format in the master repository but each person
> free to edit in their own format. But there should be a way, it only makes
> sense.
>
>
> On Jan 21, 2013, at 9:56 AM, Matthew Knepley <knepley at gmail.com> wrote:
>
> >
> > On Mon, Jan 21, 2013 at 9:51 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> >
> > On Mon, Jan 21, 2013 at 9:42 AM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > Again, the data does not support you. An incredible number of instances,
> and almost all files were changed. Thus,
> > this was far from "unconventional".
> >
> > With a version from last week (before the formatting changes):
> >
> > $ git grep '^ \+for (' src | wc -l
> > 11387
> > $ git grep '^ \+for(' src | wc -l
> > 1210
> > $ git grep '^ \+while (' src | wc -l
> > 926
> > $ git grep '^ \+while(' src | wc -l
> > 156
> > $ git grep '^ \+if (' src | wc -l
> > 22760
> > $ git grep '^ \+if(' src | wc -l
> > 129
> >
> > Is 10% small enough to be called "unconventional"?
> >
> > No.
> >
> >
> > _You_ are not even entertaining the possibility that small variability
> in source can be tolerated. That is incredibly close minded.
> >
> > You've said that the only reason you care about this is because it
> affects readability, which is exactly the reason to have consistent
> formatting guidelines in the first place.
> >
> > Absolute consistency is not axiomatic for readability. It is entirely
> possible that some portions of the code
> > are more readable with a different standard. Furthermore, readability is
> self-evidently dependent on the reader.
> > Enforcing _everything_ to be a single standard ignores this on its face.
> I assume you are also a fan of Ricardo
> > and don't have much time for Kahneman.
> >
> >    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
>
>


-- 
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/20130121/8e557530/attachment.html>