Hi, I was wondering if someone has a .clang-format file that works fine to check boost code. I looked into the github repositories, but I couldn't find any. Best regards, Damian
On 19 January 2018 at 06:22, Frédéric via Boost <boost@lists.boost.org> 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 ;-) Stuart Dootson
On 19-01-18 10:17, Stuart Dootson via Boost wrote:
On 19 January 2018 at 06:22, Frédéric via Boost <boost@lists.boost.org> 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 1/19/18 04:08, Seth via Boost wrote:
On 19-01-18 10:17, Stuart Dootson via Boost wrote:
On 19 January 2018 at 06:22, Frédéric via Boost <boost@lists.boost.org> 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.
+1 *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. michael -- Michael Caisse Ciere Consulting ciere.com
On 22. Jan 2018, at 21:00, Michael Caisse via Boost <boost@lists.boost.org> 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
*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/
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 <boost@lists.boost.org>:
*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
Hi Damian,
On 23. Jan 2018, at 14:48, Damian Vicino via Boost <boost@lists.boost.org> 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. I guess most people won't mind where you put your spaces and how many you use, as long as you don't do bad things like mixing tabs and spaces or if you are inconsistent with your style. These things can be changed later at any point with clang-format, too. One consistent thing it noticed, is a preference of underscore_separated_names over camelCase in Boost. You probably want to follow this, because that is also the style of the C++ stdlib. Boost, as a kind of unofficial extension of the C++ stdlib, generally follow its style (or perhaps the style of the stdlib follows Boost, as several libs migrated from Boost to the stdlib). Best regards, Hans
On 23 January 2018 at 15:09, Hans Dembinski via Boost <boost@lists.boost.org> wrote:
Hi Damian,
On 23. Jan 2018, at 14:48, Damian Vicino via Boost <boost@lists.boost.org> 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
Hi Mateusz,
On 23. Jan 2018, at 15:19, Mateusz Loskot <mateusz@loskot.net> wrote:
as far as I remember, there are no official rules on style
thank you for correcting my sloppy answer. I thought of style more narrowly as where to put braces and white space, but of course there are several reasonable rules about the structure of headers. I was mostly remembering this bit from
http://www.boost.org/development/header.html <http://www.boost.org/development/header.html>
"The alert reader will have noticed that the sample header <http://www.boost.org/development/header.html#SampleHeader> employs a certain coding style for indentation, positioning braces, commenting ending braces, and similar formatting issues. These stylistic issues are viewed as personal preferences and are not part of the Boost Header Policy." Best regards, Hans
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/
participants (9)
-
Damian Vicino -
Daniel Frey -
Frédéric -
Hans Dembinski -
Mateusz Loskot -
Michael Caisse -
Niall Douglas -
Seth -
Stuart Dootson