<div dir="ltr">On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matt,<div class="im"><br>
<br>
>     Again, there are limits to everything, and this surpasses the useful<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    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>
</blockquote>
<br></div>
Yes, the changes are 'enormous' if you count the absolute number of lines. However, my overall impression while refactoring was that I touched ~1% of the total code base only. It's the huge size of the code base that makes the number of changes appear to be high.<br>

<br>
Also, an estimated 50% of the violations stem from a copy&paste of older code or previous examples rather than intentionally ignoring the style guidelines. Thus, by bringing everything to a consistent state, a (large) number of such copy&paste-induced violations are no longer going to happen at all.<br>

<br>
The PETSc coding style guide needs to define exactly one style. Your style preference obviously differs. My personal preference differs slightly, too. Maybe Jed and/or others would prefer another slight variation. Nevertheless,  allowing a bit more flexibility in one's own personal coding style by following one common coding style is to the benefit of the whole project. Visual consistency is an obvious one,</blockquote>
<div><br></div><div style>Not obvious to me. Replied to this elsewhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but most importantly it aids in setting up other scripts for increased uniformity among the different PETSc modules.<br>

<br>
You may argue that it does not matter whether we have 'for(...)' or 'for (...)'. While this is certainly right for a compiler, I would like to give 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 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'. Fortunately, it is *currently* sufficient to just consider all characters other than a blank in front of 'for' to be a function call. However, one day 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 more. With a common PETSc style, the additional blank would still allow for far simpler checks and refactoring if required.<br></blockquote><div><br>
</div><div style>Any transformation which relies on whitespace is way too fragile.</div><div style><br></div><div style>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Just my 2 cents...<br>
<br>
Best regards,<br>
Karli<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>