[petsc-dev] Coding style and its violations...
Karl Rupp
rupp at mcs.anl.gov
Tue Jan 15 15:39:12 CST 2013
Hi,
>> (...)
>> 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 :-)
I'm well aware of that. :-)
>> - 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.
I'm afraid I don't understand the first sentence. I would certainly
refrain from running uncrustify in the background and thus make the SHA1
inconsistent just as Jed noted. Also, there may be corner cases where
uncrustify complains about legit code, resulting the push to fail. It's
better to refrain from such false positives and rather deal with the
more complicated checks in nightly tests.
>> 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
Alright, I'll go for it.
Best regards,
Karli
More information about the petsc-dev
mailing list