Hello:<br><br>I am working on modifying PETSc to interoperate with the MOAB mesh library. I'd love to get some of Karl's scripts to ensure that my code is compliant with the style guide. Are they available somewhere?<br>

<br>Thank You<br>Milad<br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 10:19 AM, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@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">

<div class="HOEnZb"><div class="h5">On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <<a href="mailto:rupp@mcs.anl.gov">rupp@mcs.anl.gov</a>> wrote:<br>
> Hi Matt,<br>
><br>
><br>
>>     Again, there are limits to everything, and this surpasses 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, "everyone"<br>
>> was not following the informal guidelines.<br>
><br>
><br>
> Yes, the changes are 'enormous' if you count the absolute number of lines.<br>
> However, my overall impression while refactoring was that I touched ~1% of<br>
> the total code base only. It's the huge size of the code base 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 of older<br>
> code or previous examples rather than intentionally ignoring the style<br>
> guidelines. Thus, by bringing everything to a consistent state, a (large)<br>
> number of such copy&paste-induced violations are no longer going to happen<br>
> at all.<br>
><br>
> The PETSc coding style guide needs to define exactly one style. Your style<br>
> preference obviously differs. My personal preference differs slightly, too.<br>
> Maybe Jed and/or others would prefer another slight variation. 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 project.<br>
> Visual consistency is an obvious one, but most importantly it aids in<br>
> setting up other scripts for increased uniformity among the different PETSc<br>
> modules.<br>
><br>
> You may argue that it does not matter whether we have 'for(...)' or 'for<br>
> (...)'. While this is certainly right for a compiler, I would 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 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 'for'.<br>
> Fortunately, it is *currently* sufficient to just consider all characters<br>
> other than a blank in front of 'for' to be a function call. 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 scripts any<br>
> more. With a common PETSc style, the additional blank would still allow for<br>
> far simpler checks and refactoring if required.<br>
><br>
</div></div>> Just my 2 cents…<br>
<br>
Thanks, Karl. I appreciate your effort on this front.<br>
</blockquote></div><br><br>