<div dir="ltr">All,<br><br>Just wanted to contribute some experiences we have gained at Mapbox while doing our C++ work on attempting to work towards a common format on some libraries. We have found that clang format is very helpful, but it is still also very good if you have written documentation on how to follow the style at some location. RFC seems to be the right track to gather thoughts.<br><br>The best way we have found so far to use clang format has been to check in a ".clang-format" file with each repository. Once this is done, we put in a script in our makefile to automate the updating process <a href="https://github.com/mapbox/wagyu/blob/master/Makefile#L95-L96">https://github.com/mapbox/wagyu/blob/master/Makefile#L95-L96</a> as an example.<br><br>A couple thing we have realized:<br><br>- Even experienced with a style often make mistakes as we are often shifting between projects (as they have different styles)<br>- A `make indent` (clang format) is a simple way to fix problems and check them in on occasion (such as after big changes or before releases)<br>- Optimize the style for reading now for writing of the code<br>- If you want to be really strict you can have style checked as part of testing (I am not personally a huge fan of this). <br><br>Thanks,<br><br>Blake Thompson<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 5, 2017 at 1:04 PM, Kurt Schwehr <span dir="ltr"><<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>astyle would certainly work too.</div><div><br></div>I find clang-format more robust than almost all other formatting tools as Mateusz described.  As for workflow, there are multiple possible routes as to how to go about this.  I personally write pretty messy code when I'm working and then just do a format pass before submitting.  If the editor I'm using supports formatting, great.  However, the command line is super easy.  I also know a number of people who work on code only after applying their own person clang format style to code and then transform back before submitting.  And there is the critical ability to shut off the formatter for sections of code where the formatter will do something seriously wrong... the classic example is matrices in test files. <div><br></div><div>Alternatively, we could easily have astyle as a first pass to add braces before clang-format if someone wanted to implement that.  But there clang-tidy as Mateusz said with:</div><div><br></div><div><a href="https://clang.llvm.org/extra/clang-tidy/checks/readability-braces-around-statements.html" target="_blank">https://clang.llvm.org/extra/<wbr>clang-tidy/checks/readability-<wbr>braces-around-statements.html</a><br></div><div><br></div><div>with lots of other check....</div><div><br></div><div><a href="https://clang.llvm.org/extra/clang-tidy/checks/list.html" target="_blank">https://clang.llvm.org/extra/<wbr>clang-tidy/checks/list.html</a><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, May 5, 2017 at 4:46 AM, Mateusz Loskot <span dir="ltr"><<a href="mailto:mateusz@loskot.net" target="_blank">mateusz@loskot.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 5 May 2017 at 13:35, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br>
><br>
> In case we want to have a policy regarding braces around single statements,<br>
> one finding coming from the openjpeg discussion I mentionned :<br>
><br>
> """<br>
> Moreover, concerning braces around single statements, it seems astyle does<br>
> this with the add-braces option:<br>
> <a href="http://astyle.sourceforge.net/astyle.html#_add-braces" rel="noreferrer" target="_blank">http://astyle.sourceforge.net/<wbr>astyle.html#_add-braces</a><br>
> As far as I understood, clang-format does not, and requires another tool<br>
> (clang-tidy) to deal with these cases. So one more point for astyle.<br>
> """<br>
<br>
</span>Rather, it is a separation of concerns: linting vs formatting<br>
AFAIU, clang-format does not modify any code (ie. add tokens).<br>
<br>
I'm not clang-format advocate. I'll repeat myself:<br>
My personal preference is to use clang-format.<br>
I proposed it to GEOS via GEOS RFC.<br>
Kurt found the RFC useful and is using it as a template<br>
to prepare one for GDAL.<br>
IMHO, at the end of the day, tool does not matter as long as proposed<br>
goals are achieved.<br>
<div class="m_6508186349038979392HOEnZb"><div class="m_6508186349038979392h5"><br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_6508186349038979392gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div>