[petsc-dev] Coding style and its violations...

[Karl Rupp]

Hi,

 > Many/most of these are not really violations, the guideline just isn't
> written precisely enough.
> http://krupp.iue.tuwien.ac.at/petsc-style/closing-bracket.txt

Yeah, I also noticed that the style guide lacks some additional 
precision. I plan to eliminate the obvious violations first and then 
refine the filter and discuss corner cases.

> A lot of these are in comments:
> http://krupp.iue.tuwien.ac.at/petsc-style/else-indentation.txt

Yes - looks like I need to send the whole thing through some filter 
stripping out comments first. Looks like GCC can do that with
$> gcc -fpreprocessed -dD -E file.c

> Use of // in comments is okay (/* does not nest)
> http://krupp.iue.tuwien.ac.at/petsc-style/cpp-comments.txt

Yes, see above.

> There's also this absolute insanity that true C++ source files
> (associated with Sieve) are named with *.c. It's probably worth ignoring
> everything in src/dm/impls/mesh/ because that code is scheduled for
> deletion once certain projects migrate over to DMPlex.

Yes, that's also something I noted for discussion once I've eliminated 
the obvious violations.

Thanks,
Karli


>
>
> On Thu, Jan 17, 2013 at 4:05 PM, Karl Rupp <rupp at mcs.anl.gov
> <mailto:rupp at mcs.anl.gov>> wrote:
>
>     Hello again,
>
>     I've set up a couple of scripts checking for compliance with the
>     coding styles and started with the removal of tabs. There's also a
>     little page set up for tracking the current progress (i.e. the work
>     left to be done):
>     http://krupp.iue.tuwien.ac.at/__petsc-style/
>     <http://krupp.iue.tuwien.ac.at/petsc-style/>
>     The page is automatically generated from a bash script calling the
>     various checker scripts and may be run nightly via a cron job.
>     Further details on the violations can be found when clicking on the
>     number of violations found. My goal is to reach 'all green' within
>     the next couple of days and then to integrate the 'most failsafe'
>     scripts into Mercurial.
>
>     I'm also thinking about a similar simple overview page for the
>     nightly tests, but that's a different story...
>
>     Best regards,
>     Karli
>
>
>
>
>     On 01/15/2013 02:47 PM, Barry Smith wrote:
>
>
>         On Jan 15, 2013, at 2:42 PM, Karl Rupp <rupp at mcs.anl.gov
>         <mailto: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
>
>
>
>