On Jan 15, 2013, at 2:42 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> Dear all,
>
> quoting a recent commit:
>
> > BarryFSmith committed 16 hours ago (raw commit)
> >
> > silly code formatting problems; some people still need to read the
> > style guide
>
> So we have a style guide that is partially respected, partially ignored. Some
> things are pretty hard to check automatically, while others are rather
> simple. So let's pick
> "No tabs are allowed in any of the source code."
> as an example and run
>
> $petsc-dev/src> find . -name *.h -type f | xargs grep -P '\t' | wc -l
>
> to pick the number of violations in .h-files. I get 3215 hits, which is still
> small compared to the 8797 hits in .c-files.
It takes little more time to fix the problem then detect it :-)
>
> So, what can we do to reduce the number of violations of the style guide and
> keep the number of violations as small as possible in the future?
>
> - First and foremost, eliminate (as many of the) existing violations (as
> possible) and come to a clean state.
Yes
>
> - Run pre-push-scripts on bitbucket on the diff. They may not find all
> violations, but at least check for the most obvious ones.
Yes. Jed is too in love with Git to ever do this so you have to.
>
> - Add nightly tests on the source tree. We can compare the output of a
> properly configured uncrustify against the existing source files and complain
> on a mismatch.
The problem is that uncrustify is exactly the PETSc style so we can't do
that comparison automatically. Otherwise we would just run uncrustify on all
pushes.
>
> Unless there are objections, I'm willing to devote some time on that while
> playing with options for a better testing environment. I don't think that a
> full elimination of all violations is ever possible nor reasonably
> attainable. However, a reduction of violations simplifies the handling of the
> code base considerably and is thus worth the effort.
Yes
>
> Best regards,
> Karli
>
