<div dir="ltr"><div>Yes, clang-format is really good; it&#39;s playing in a different league than GNU indent or other prehistoric predecessors. It turns out that clang-format does not chase include statements nor requires knowledge about #define statements, and can thus format each file in isolation. It uses clang&#39;s parser, but does not construct the detailed semantic tree structures that clang needs to resolve types. Thus clang-format stays closer to how a human reads code than how a compiler interprets it.</div><div><br></div><div>Yes, older versions of clang-format had problems in some special cases. I&#39;ve encountered issues in hairy template arguments, where clang-format gets confused about the meaning of &quot;&lt;&quot; (template argument or less-than sign?) and &quot;&amp;&amp;&quot; (binary operator or rvalue prefix?). Newer versions of clang-format get this right; otherwise, one can use parentheses to make the meaning clear. Note that these are really dark corners of C++, where it is impossible to tell the difference without knowing whether certain identifiers are types or variables, which depends on details of scoping and namespaces and all previous include files.</div><div><br></div><div>Anyway -- we should easily be able to all use the same version of clang-format.</div><div><br></div><div>-erik</div><div><br></div>On Wed, Jul 8, 2015 at 9:39 AM, Steven R. Brandt <span dir="ltr">&lt;<a href="mailto:sbrandt@cct.lsu.edu" target="_blank">sbrandt@cct.lsu.edu</a>&gt;</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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>On one hand, clang-format ought to be
      really good because it can leverage the clang parser and
      understand the code as well as the compiler. Other tools have to
      re-engineer the whole process and may not get it exactly right.
      I&#39;m rarely completely happy with auto-format, and because of that
      I only ever apply it to small areas of code at a time.<br>
      <br>
      On the other hand, there is a potential version issue. I just
      formatted a simple code with two versions of clang-format I had
      installed on my laptop and got different results. The older
      version messed up the formatting of a C++11 initializer. While the
      C++11 issues are probably not going to be a problem going forward,
      other issues might crop up. I could easily imagine bits of
      formatting changing back and forth as two developers with
      different versions of clang updated the source.<br>
      <br>
      Cheers,<br>
      Steve<div><div class="h5"><br>
      <br>
      On 07/07/2015 10:51 AM, Erik Schnetter wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <div dir="ltr">Yeah, that&#39;s what I thought in the beginning --
        code formatting is all about indentation, which is handled by
        the tab key. But it turns out, it isn&#39;t. I only noticed after
        using clang-format for some way. Code formatting ties up part of
        your brain, every time you type a character, you have to ask
        yourself &quot;do I need to insert a space&quot;, &quot;do not need to insert a
        line break&quot;, &quot;should I join these two lines again&quot;, &quot;does this
        comments need re-formatting&quot;, &quot;should I line-wrap this lengthy
        expression differently&quot;, &quot;how do I make these lines line up
        nicely&quot;, etc.
        <div><br>
        </div>
        <div>With clang-format -- none of this. You type in the content
          you want, you insert spaces where absolutely necessary, you
          save, and when you look again, the code looks nice. And you
          can relax in the knowledge that this formatting is a
          projection -- there&#39;s no &quot;other way&quot; that maybe might look
          better.</div>
        <div><br>
        </div>
        <div>Also, clang-format doesn&#39;t indent namespaces the way the
          tab key does, and it doesn&#39;t make errors. Clang-format is the
          complete separation of form and content, and you only have to
          care about the latter. Think of it as latex: You type the
          text, and it will look well-formatted without requiring any
          manual input. You may think that latex isn&#39;t necessary and
          that manually formatted text will look just as nice -- and
          you&#39;re probably right, in almost all cases manual formatting
          would look nice enough to do the trick. But there is a
          fundamental difference between latex and manual formatting,
          and it&#39;s good to have it.</div>
        <div><br>
        </div>
        <div>So: Yes, this is worth it.</div>
        <div><br>
        </div>
        <div>Regarding various versions of clang-format: There are (of
          course) also many options you can set, although I just go with
          the default, which is very good. Yes, there are probably
          difference between versions (improvements, e.g. for handling
          template arguments). I&#39;m sure we could settle on a standard
          version, or a standard set of options.</div>
        <div><br>
        </div>
        <div>-erik</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Jul 6, 2015 at 5:56 PM, Ian
          Hinder <span dir="ltr">&lt;<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div style="word-wrap:break-word"><br>
              <div>
                <div>
                  <div>
                    <div>On 4 Jul 2015, at 17:06, Erik Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>&gt;
                      wrote:</div>
                    <br>
                    <blockquote type="cite">
                      <div dir="ltr">On Sat, Jul 4, 2015 at 10:30 AM,
                        Ian Hinder <span dir="ltr">&lt;<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>&gt;</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">
                              <div style="word-wrap:break-word"><br>
                                <div><span>
                                    <div>On 3 Jul 2015, at 23:33, Erik
                                      Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>&gt;
                                      wrote:</div>
                                    <br>
                                    <blockquote type="cite">
                                      <div dir="ltr">I&#39;ve come to like
                                        to use a tool to automatically
                                        indent and format source code.
                                        This has several advantages --
                                        the code has automatically a
                                        consistent style, indentation
                                        errors become obvious, and one
                                        doesn&#39;t have to spend time
                                        formatting the code manually
                                        while coding.
                                        <div><br>
                                        </div>
                                        <div>clang-format is the best
                                          such tool of which I&#39;m aware.
                                          It&#39;s vastly better than e.g.
                                          GNU indent.</div>
                                        <div><br>
                                        </div>
                                        <div>I propose to re-format
                                          Carpet&#39;s source code via
                                          clang-format.</div>
                                        <div><br>
                                        </div>
                                        <div>Usually, changing the
                                          source code format is
                                          disruptive, since patches or
                                          local modifications won&#39;t
                                          apply cleanly any more.
                                          However, with clang-format, I
                                          don&#39;t think that this is an
                                          issue -- one can use
                                          clang-format on the modified
                                          code (e.g. a branch), which
                                          should eliminate gratuitous
                                          changes.</div>
                                      </div>
                                    </blockquote>
                                    <blockquote type="cite">
                                      <div dir="ltr">
                                        <div><br>
                                        </div>
                                        <div>Please comment.</div>
                                      </div>
                                    </blockquote>
                                    <div><br>
                                    </div>
                                  </span>
                                  <div>Suppose that I have a local
                                    branch with a number of commits (I
                                    do).  If I want to cherry-pick
                                    something from the new reformatted
                                    master, I could add a new commit to
                                    my branch which reformats
                                    everything, and cherry-picking would
                                    hopefully then be possible.  To
                                    rebase my branch off of the
                                    reformatted master, I would probably
                                    have to rebase it off the commit in
                                    master before the reformat, then
                                    apply the reformatting myself, then
                                    rebase again of the new master.  So
                                    apart from the amount of
                                    git-gymnastics needed to do this, it
                                    seems OK.  More serious would be the
                                    utter impossibility of diffing
                                    formaline tarballs across the change
                                    and identifying the real
                                    differences.</div>
                                  <div><br>
                                  </div>
                                  <div>I hope it doesn&#39;t need to be
                                    said, but any commits which
                                    introduce reformatting should be
                                    clearly labeled as such, and should
                                    not introduce any other changes, as
                                    these will be lost during a rebase
                                    in which formatting commits are
                                    skipped and formatting run again.</div>
                                  <div><br>
                                  </div>
                                  <div>With the above considerations, is
                                    it worth doing this?</div>
                                </div>
                              </div>
                            </blockquote>
                            <div><br>
                            </div>
                            <div>Yes, it definitively is. Not having to
                              worry about indentation and formatting
                              while coding frees the mind; it is a
                              transformative experience.</div>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                    <div><br>
                    </div>
                  </div>
                </div>
                <div>I just press TAB in emacs to make sure the
                  indentation is correct; it&#39;s not something I ever
                  really think about.  After reading Roland&#39;s email, I&#39;m
                  more and more concerned that a large-scale
                  reformatting of an existing codebase with several
                  branches owned by different people is going to cause a
                  fair amount of pain.  For a new project, I would
                  definitely use such a system, and when new code is
                  added to an existing project, but I&#39;m not sure it&#39;s
                  worth the trouble it will cause for Carpet.</div>
              </div>
              <span><br>
                <div>
                  <div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
                    <div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
                      <div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
                        <div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
                          <div>-- </div>
                          <div>Ian Hinder</div>
                          <div><a href="http://members.aei.mpg.de/ianhin" target="_blank">http://members.aei.mpg.de/ianhin</a></div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
                <br>
              </span></div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div>Erik Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>&gt;<br>
          <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
Users mailing list
<a href="mailto:Users@einsteintoolkit.org" target="_blank">Users@einsteintoolkit.org</a>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Erik Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>&gt;<br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div></div>