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 > > > >
