Mehdi Amini via llvm-dev
2017-Jan-09 19:04 UTC
[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
> On Jan 9, 2017, at 10:29 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9 January 2017 at 18:20, Reid Kleckner <rnk at google.com> wrote: >> I object to the first. If you need a new type name, use a typedef. It's time >> honored and everyone, including C programmers, will know what you're doing. >> I don't understand why people push the new thing just for the sake of >> new-ness. > > The text read "prefer", which I think it's fair. I'm opposed to any > hard rule for the sake of new-ness, consistency, or personal > preference. > > If we encode all nit-rules as "prefer", then it should be more like a > guideline than a rule book, which has been our motto for everything > else.This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formatting — Mehdi
Renato Golin via llvm-dev
2017-Jan-09 20:47 UTC
[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
On 9 January 2017 at 19:04, Mehdi Amini <mehdi.amini at apple.com> wrote:> This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formattingYou mistake the tone of the documentation. There are things that cannot be (exceptions, RTTI), things that are important to get right (includes vs. forward declaration), things that are preferred (c++11-isms) and things that are optional and very much depends on the situation. The four items in the list I replied to fall into the latter category. The tone used for each type is appropriate to its enforcement. If you add compiler errors or warnings, it's pretty easy to enforce. Everything else will have varying degrees of success, and being obnoxious about it has never been, and I hope never will be, our way. We don't force people to run clang-format on patches, we ask when it's ugly and people do because they believe it's a good thing. When the formatting doesn't hurt my eyes, I don't ask for clang-format. I certainly won't start asking people to run clang-tidy, though I'd be happy if they did. That's personal and with the volume of commits we have, that last thing we need is people blocking or reverting patches because they didn't conform to personal preferences, even if they were encoded in the coding standards. I also strongly oppose to encoding personal preferences with a stronger wording that it's warranted. Personal is personal. If it's legal C++ and it's an appropriate use of the language for the case at hand, than it's fine. I couldn't care less if you use "using" or "typedef". I can understand both. "Prefer using" is an interesting proposition, but refuse patches because they have "typedefs" is silly. Honestly, my "coding standards" would be as simple as "do whatever Scott Meyers says you should", but the LLVM one is nice, too. Unless it's used as a weapon. cheers, --renato
Mehdi Amini via llvm-dev
2017-Jan-09 20:48 UTC
[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
> On Jan 9, 2017, at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 9 January 2017 at 19:04, Mehdi Amini <mehdi.amini at apple.com> wrote: >> This is not correct according to the number of “should” and the imperative tone for many aspects of http://llvm.org/docs/CodingStandards.html#source-code-formatting > > You mistake the tone of the documentation.Either one of us is mistaken, but I find yourself being fairly confident here… Try going above the 80 cols and defend it as your personal preference in a review, and let me know how it went. — Mehdi> There are things that > cannot be (exceptions, RTTI), things that are important to get right > (includes vs. forward declaration), things that are preferred > (c++11-isms) and things that are optional and very much depends on the > situation. The four items in the list I replied to fall into the > latter category. > > The tone used for each type is appropriate to its enforcement. If you > add compiler errors or warnings, it's pretty easy to enforce. > Everything else will have varying degrees of success, and being > obnoxious about it has never been, and I hope never will be, our way. > > We don't force people to run clang-format on patches, we ask when it's > ugly and people do because they believe it's a good thing. When the > formatting doesn't hurt my eyes, I don't ask for clang-format. I > certainly won't start asking people to run clang-tidy, though I'd be > happy if they did. That's personal and with the volume of commits we > have, that last thing we need is people blocking or reverting patches > because they didn't conform to personal preferences, even if they were > encoded in the coding standards. > > I also strongly oppose to encoding personal preferences with a > stronger wording that it's warranted. Personal is personal. If it's > legal C++ and it's an appropriate use of the language for the case at > hand, than it's fine. I couldn't care less if you use "using" or > "typedef". I can understand both. "Prefer using" is an interesting > proposition, but refuse patches because they have "typedefs" is silly. > > Honestly, my "coding standards" would be as simple as "do whatever > Scott Meyers says you should", but the LLVM one is nice, too. Unless > it's used as a weapon. > > cheers, > --renato
Maybe Matching Threads
- [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
- [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
- [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
- [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
- [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy