[petsc-dev] I hate this one

Barry Smith bsmith at mcs.anl.gov
Mon Jan 21 17:59:39 CST 2013


  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.

   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




More information about the petsc-dev mailing list