[cfe-dev] clang-format Style for RTEMS

Oto BREZINA via cfe-dev cfe-dev at lists.llvm.org
Fri Jan 4 04:01:08 PST 2019


I can tell you I did in our smallish company I found best fitting 
clang-format settings for our style to run on files, after 
clang-formater is done I run sed. This gives 99% good formatting instead 
of 90%.

Maybe instead of adding new switch per tweak one language as 
regularexpresion is in my case can let user formatting possible, or just 
run run sed afterwards.

Oto



>>>> Which is really disappointing from an OSS project...
>>>>
>>>> That a new language like Go forces a given style is OK,
>>>> since their "one-true-format" existing from the beginning of the
>>> language.
>>>> But that clang-format rejects even the idea of a widely used style of
>>> closing
>>>> parens being on their own line, similar to how curlies are for blocks,
>>> on code
>>>> bases which have used those styles for decades, just because 3 large
>>> corporations
>>>> use different styles, is a clear sign something's not right here.
>>>>
>>>> Options to support such a style were discussed several times on this
>>> list, and I haven't
>>>> been lurking for very long either, so it's not like this is a one-off
>>> and seldom used style.
>>>> Adopting clang-format on a codebase should strive for minimal changes
>>> to well-formatted
>>>> code using a given local style guide, minimising diffs at the SCM level.
>>>>
>>>> It's also frankly a bit condescending to imply all those peoples (and
>>> their millions of lines of code,
>>>> quite literally) are using somehow a "wrong style" not "worthy" of
>>> changing clang-format over.
>>>> Oleg's reply is friendly and polite, no question there, but what it
>>> implies is offending IMHO.
>>>
>>> Have you seen
>>> https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>>> ?
>>> More options, while certainly allows for more customizability, is
>>> always more code, tests,
>>> behavior to preserve and account for going forward.
>>>
>>>> FWIW... --DD
>>> Roman.
>>


More information about the cfe-dev mailing list