Thanks Karl!<br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 10:38 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Milad,<br>
<br>
the checks are in src/contrib/style/checks/. You can run them from PETSC_DIR, but they currently check the full source tree only. Compare with<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/</a><br>
to see whether you've introduced additional 'violations'. You can also generate the full HTML output by running src/contrib/style/runhtml.sh from PETSC_DIR and view/compare the output in src/contrib/style/html/index.<u></u>html<br>
<br>
Best regards,<br>
Karli<div class="im"><br>
<br>
<br>
On 02/13/2013 10:32 AM, Milad Fatenejad wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello:<br>
<br>
I am working on modifying PETSc to interoperate with the MOAB mesh<br>
library. I'd love to get some of Karl's scripts to ensure that my code<br>
is compliant with the style guide. Are they available somewhere?<br>
<br>
Thank You<br>
Milad<br>
<br>
On Mon, Jan 21, 2013 at 10:19 AM, Sean Farley <<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a><br></div><div class="im">
<mailto:<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a>>> wrote:<br>
<br>
On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a><br></div><div><div class="h5">
<mailto:<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>>> wrote:<br>
> Hi Matt,<br>
><br>
><br>
>> Again, there are limits to everything, and this surpasses<br>
the useful<br>
>><br>
>> limit to this kind of specification. This is not personal<br>
>> expression, this<br>
>> is ease of reading.<br>
>><br>
>><br>
>> Also, judging by the ENORMOUS number of source code changes,<br>
"everyone"<br>
>> was not following the informal guidelines.<br>
><br>
><br>
> Yes, the changes are 'enormous' if you count the absolute number<br>
of lines.<br>
> However, my overall impression while refactoring was that I<br>
touched ~1% of<br>
> the total code base only. It's the huge size of the code base<br>
that makes the<br>
> number of changes appear to be high.<br>
><br>
> Also, an estimated 50% of the violations stem from a copy&paste<br>
of older<br>
> code or previous examples rather than intentionally ignoring the<br>
style<br>
> guidelines. Thus, by bringing everything to a consistent state, a<br>
(large)<br>
> number of such copy&paste-induced violations are no longer going<br>
to happen<br>
> at all.<br>
><br>
> The PETSc coding style guide needs to define exactly one style.<br>
Your style<br>
> preference obviously differs. My personal preference differs<br>
slightly, too.<br>
> Maybe Jed and/or others would prefer another slight variation.<br>
Nevertheless,<br>
> allowing a bit more flexibility in one's own personal coding style by<br>
> following one common coding style is to the benefit of the whole<br>
project.<br>
> Visual consistency is an obvious one, but most importantly it aids in<br>
> setting up other scripts for increased uniformity among the<br>
different PETSc<br>
> modules.<br>
><br>
> You may argue that it does not matter whether we have 'for(...)'<br>
or 'for<br>
> (...)'. While this is certainly right for a compiler, I would<br>
like to give<br>
> you one example where it *does* make a difference:<br>
> src/mat/interface/matrix.c:<br>
> PetscErrorCode MatSetValuesAdifor(Mat mat,PetscInt nl,void *v)<br>
> So, keeping consistency with the style guide, we would write<br>
> for (...) {...}<br>
> MatSetValuesAdifor(...) {...}<br>
> and there is the additional blank contributing to the difference<br>
between the<br>
> function call and the for-loop. If, however, we have<br>
> for(...) {...}<br>
> MatSetValuesAdifor(...) {...}<br>
> any scripts additionally need to check for characters in front of<br>
'for'.<br>
> Fortunately, it is *currently* sufficient to just consider all<br>
characters<br>
> other than a blank in front of 'for' to be a function call.<br>
However, one day<br>
> we might find code such as<br>
> do_something(...);for(...) {...};<br>
> or even<br>
> cilk_for(...)<br>
> and all of a sudden we are unable to use any simple checker<br>
scripts any<br>
> more. With a common PETSc style, the additional blank would still<br>
allow for<br>
> far simpler checks and refactoring if required.<br>
><br>
> Just my 2 cents…<br>
<br>
Thanks, Karl. I appreciate your effort on this front.<br>
<br>
<br>
</div></div></blockquote></blockquote></div>