On 19-01-18 10:17, Stuart Dootson via Boost wrote:

On 19 January 2018 at 06:22, Frédéric via Boost wrote:

...

...

I was wondering if someone has a .clang-format file that works fine to check boost code. It would be great to have the same presentation in every file!

You could try using Unformat (https://github.com/johnmcfarlane/unformat) to generate one from the Boost code base... And then run the Boost code base through it to make it fully consistent with it ;-)

I completely don't expect any consistent style(s) to emerge. Moreover heavy template/macro chicanery is usually exeptional - or suffers badly in terms of readability. In short, no there won't be a format that works. Even if you decide on one, that would mean that **all** libraries take massive change-sets to adhere to it, which wreaks havoc with respect to merge/diff stability, IME. You **could** make a default format file that is **in principle** endorsed by Boost. And then require new code to adhere to it, and allow existing code to be reformatted upon maintenance. Reliable improvement is always incremental.

On 22. Jan 2018, at 21:00, Michael Caisse via Boost wrote:

*Please* do not mess up the source code. Some of us believe that there is an art involved to writing beautiful code. The white space formatting of heavy template code, macros, and EDSL's makes the code understandable to humans.

Clang-format and other such tools destroy readability and understanding in many code bases. Don't believe me? Take a look at well written Proto, Spirit, MSM, or MPL/Fusion heavy sources written by someone who believes that code should be beautiful. Now run it through your favorite format-tool and observe the horrible mess that emerges.

While I agree in general, there are also ways to have both. In our little project, we decided to have a consistent and automated style, enforced by clang-format. But there are sections of code which are hand-formatted, you can simply augment them with comments to turn clang-format off and later on again. As an example, see https://github.com/taocpp/PEGTL/blob/master/src/example/pegtl/unescape.cpp. Nevertheless, reformatting all of Boost seems like a terrible idea right now. It might be an option for those libraries/maintainers that want to use a consistent style in the future and stop debating over it, still having the possibility to exclude some sections from auto-formatting. Regardless, someone has to come up with an agreeable style first anyways... Daniel

Hi, I see I opened an interesting discussion, but my original question was way more inocent. I just wanted to format my code before sending it for review :) I agree for templates and even for long conditions it is better to be flexible. I only expected very basic things to be declared like, how many spaces for indentation, braces positions (next line or same line), underscore_separated_names and not camelCase. Since there is nothing, I will write one for my project and include it in the review as an starting point. Best regards, Damian 2018-01-23 4:23 GMT-05:00 Niall Douglas via Boost :

...

*Please* do not mess up the source code. Some of us believe that there is an art involved to writing beautiful code. The white space formatting of heavy template code, macros, and EDSL's makes the code understandable to humans

Clang-format and other such tools destroy readability and understanding in many code bases. Don't believe me? Take a look at well written Proto, Spirit, MSM, or MPL/Fusion heavy sources written by someone who believes that code should be beautiful. Now run it through your favorite format-tool and observe the horrible mess that emerges.

Best of course is that you write your source with clang-format always running, that way you can poke it as you go to not mess up formatting where appropriate.

But I have "ported" legacy codebases to clang-format in the past. It takes a few days, but thereafter it can be cronjobbed and never again do things like tabs or failure to follow the style guide ever occur again. In this situation, stick is much better than carrot. Give developers zero choice on formatting, then the problem becomes not a problem.

Niall

-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

On 23 January 2018 at 15:09, Hans Dembinski via Boost wrote:

Hi Damian,

...

On 23. Jan 2018, at 14:48, Damian Vicino via Boost wrote:

...

I only expected very basic things to be declared like, how many spaces for indentation, braces positions (next line or same line), underscore_separated_names and not camelCase.

as far as I remember, there are no official rules on style

There is basic rules set http://www.boost.org/development/requirements.html http://www.boost.org/development/header.html

One consistent thing it noticed, is a preference of underscore_separated_names over camelCase in Boost.

This aspect is actually specified in the rules linked above.

You probably want to follow this, because that is also the style of the C++ stdlib.

Rather, because that is Boost requirement (as per the rules). Some Boost libraries extended the rules and developed more specific guidelines, for example https://github.com/boostorg/geometry/wiki/Guidelines-for-Developers Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 23/01/2018 13:48, Damian Vicino wrote:

Hi,  I see I opened an interesting discussion, but my original question was way more inocent. I just wanted to format my code before sending it for review :)

All of the recently added Boost libraries that I can remember have had a .clang-format in their root. That suggests a precedent. Increasing numbers also come with a .clang-tidy, though I note that I am unusual for turning on all checks by default and explicitly disabling the stupid ones. Outcome as submitted is clang-tidy clean. Almost nobody appears to be running clang-tidy on their Windows builds, though it actually works fine. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/