Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > On Mon, 19 Sep 2016, Joe Perches wrote: > > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > > IMO what we need is to go through all rules in CodingStyle and if for > > > > some rule there is no overwhelming majority in the core kernel, well, > > > > the list has grown way too large and could use massive trimming. > > > > > > I'm in complete agreement. > > > > > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > > > far too severe and injunctive and could use a renaming to something > > > more silly, bug related and less commanding like FLEAS/GNATS/NITS. > > I think it is better to be clear. CHECK was never really clear to me, > > especially if you see it in isolation, on a file that doesn't also have > > ERROR or WARNING. NITS is a common word in this context, but not FLEAS > > and GNATS, as far as I know. > > There could also be a severity level: high medium and low > > I agree clarity is good. > > The seriousness with which some beginners take these message > types though is troublesome, It's not necessarily the case that changing the error type will change the behavior of the persons in question. > Maybe prefix various different types of style messages. > > Something like: > > ERROR -> CODE_STYLE_DEFECT > WARNING -> CODE_STYLE_UNPREFERRED > CHECK -> CODE_STYLE_NIT > > I doubt additional external documentation would help much. > > Some checkpatch bleats really are errors though. Maybe just downgrade more things? Perhaps SUGGESTION would be more clear than CHECK? julia
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > > On Mon, 19 Sep 2016, Joe Perches wrote: > > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > > IMO what we need is to go through all rules in CodingStyle and if for > > > > some rule there is no overwhelming majority in the core kernel, well, > > > > the list has grown way too large and could use massive trimming. > > > > > > I'm in complete agreement. > > > > > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > > > far too severe and injunctive and could use a renaming to something > > > more silly, bug related and less commanding like FLEAS/GNATS/NITS. > > I think it is better to be clear. CHECK was never really clear to me, > > especially if you see it in isolation, on a file that doesn't also have > > ERROR or WARNING. NITS is a common word in this context, but not FLEAS > > and GNATS, as far as I know. > > There could also be a severity level: high medium and low > > I agree clarity is good. > > The seriousness with which some beginners take these message > types though is troublesome, It's not necessarily the case that changing the error type will change the behavior of the persons in question. > Maybe prefix various different types of style messages. > > Something like: > > ERROR -> CODE_STYLE_DEFECT > WARNING -> CODE_STYLE_UNPREFERRED > CHECK -> CODE_STYLE_NIT > > I doubt additional external documentation would help much. > > Some checkpatch bleats really are errors though. Maybe just downgrade more things? Perhaps SUGGESTION would be more clear than CHECK? julia
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > On Mon, 19 Sep 2016, Joe Perches wrote: > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > IMO what we need is to go through all rules in CodingStyle and if for > > > some rule there is no overwhelming majority in the core kernel, well, > > > the list has grown way too large and could use massive trimming. > > > > I'm in complete agreement. > > > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > > far too severe and injunctive and could use a renaming to something > > more silly, bug related and less commanding like FLEAS/GNATS/NITS. > I think it is better to be clear. CHECK was never really clear to me, > especially if you see it in isolation, on a file that doesn't also have > ERROR or WARNING. NITS is a common word in this context, but not FLEAS > and GNATS, as far as I know. > There could also be a severity level: high medium and low I agree clarity is good. The seriousness with which some beginners take these message types though is troublesome, Maybe prefix various different types of style messages. Something like: ERROR -> CODE_STYLE_DEFECT WARNING -> CODE_STYLE_UNPREFERRED CHECK -> CODE_STYLE_NIT I doubt additional external documentation would help much. Some checkpatch bleats really are errors though.
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Tue, 2016-09-20 at 07:53 +0200, Julia Lawall wrote: > On Mon, 19 Sep 2016, Joe Perches wrote: > > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > > IMO what we need is to go through all rules in CodingStyle and if for > > > some rule there is no overwhelming majority in the core kernel, well, > > > the list has grown way too large and could use massive trimming. > > > > I'm in complete agreement. > > > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > > far too severe and injunctive and could use a renaming to something > > more silly, bug related and less commanding like FLEAS/GNATS/NITS. > I think it is better to be clear. CHECK was never really clear to me, > especially if you see it in isolation, on a file that doesn't also have > ERROR or WARNING. NITS is a common word in this context, but not FLEAS > and GNATS, as far as I know. > There could also be a severity level: high medium and low I agree clarity is good. The seriousness with which some beginners take these message types though is troublesome, Maybe prefix various different types of style messages. Something like: ERROR -> CODE_STYLE_DEFECT WARNING -> CODE_STYLE_UNPREFERRED CHECK -> CODE_STYLE_NIT I doubt additional external documentation would help much. Some checkpatch bleats really are errors though.
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > IMO what we need is to go through all rules in CodingStyle and if for > > some rule there is no overwhelming majority in the core kernel, well, > > the list has grown way too large and could use massive trimming. > > I'm in complete agreement. > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > far too severe and injunctive and could use a renaming to something > more silly, bug related and less commanding like FLEAS/GNATS/NITS. I think it is better to be clear. CHECK was never really clear to me, especially if you see it in isolation, on a file that doesn't also have ERROR or WARNING. NITS is a common word in this context, but not FLEAS and GNATS, as far as I know. There could also be a severity level: high medium and low. julia > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, 19 Sep 2016, Joe Perches wrote: > On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > > IMO what we need is to go through all rules in CodingStyle and if for > > some rule there is no overwhelming majority in the core kernel, well, > > the list has grown way too large and could use massive trimming. > > I'm in complete agreement. > > I also think that checkpatch's ERROR/WARNING/CHECK message naming is > far too severe and injunctive and could use a renaming to something > more silly, bug related and less commanding like FLEAS/GNATS/NITS. I think it is better to be clear. CHECK was never really clear to me, especially if you see it in isolation, on a file that doesn't also have ERROR or WARNING. NITS is a common word in this context, but not FLEAS and GNATS, as far as I know. There could also be a severity level: high medium and low. julia > > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > IMO what we need is to go through all rules in CodingStyle and if for > some rule there is no overwhelming majority in the core kernel, well, > the list has grown way too large and could use massive trimming. I'm in complete agreement. I also think that checkpatch's ERROR/WARNING/CHECK message naming is far too severe and injunctive and could use a renaming to something more silly, bug related and less commanding like FLEAS/GNATS/NITS.
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote: > IMO what we need is to go through all rules in CodingStyle and if for > some rule there is no overwhelming majority in the core kernel, well, > the list has grown way too large and could use massive trimming. I'm in complete agreement. I also think that checkpatch's ERROR/WARNING/CHECK message naming is far too severe and injunctive and could use a renaming to something more silly, bug related and less commanding like FLEAS/GNATS/NITS.
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote: > > I did consider the reason to be good enough to warrant a "change", > > actually. Or more exactly from "one space is allowed" to "one space is > > recommended." Which is quite different from changing all the code > > actively. I can understand how you don't like it, but again, this > > "inconsistency" has been accepted for almost a decade now, so I find it > > strange to see so much resistance when someone finally tries to sort it > > out. > > Yeah, I guess that's where our disagreement lies - the "so that `diff > -p` does not confuse labels with functions" in the age of git, hg and > others, all of which can be customized to your heart's content is not > a good enough reason to go from "allowed" to "advised". On the top of CodingStyle we have "This is a short document describing the preferred coding style for the linux kernel." Let's make it s/describing/& (as in "descriptive, not prescriptive")/. The lack of consensus (in the core kernel areas) is _not_ an invitation to pick a rule out of one's arse/nose/armpit/textbook/whatnot and stick it as The One True Style, and references to uniformity are worthless in such case. In particular, "whitespace before labels" kind of patches anywhere in VFS will be simply rejected. IMO what we need is to go through all rules in CodingStyle and if for some rule there is no overwhelming majority in the core kernel, well, the list has grown way too large and could use massive trimming.
Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())
On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote: > > I did consider the reason to be good enough to warrant a "change", > > actually. Or more exactly from "one space is allowed" to "one space is > > recommended." Which is quite different from changing all the code > > actively. I can understand how you don't like it, but again, this > > "inconsistency" has been accepted for almost a decade now, so I find it > > strange to see so much resistance when someone finally tries to sort it > > out. > > Yeah, I guess that's where our disagreement lies - the "so that `diff > -p` does not confuse labels with functions" in the age of git, hg and > others, all of which can be customized to your heart's content is not > a good enough reason to go from "allowed" to "advised". On the top of CodingStyle we have "This is a short document describing the preferred coding style for the linux kernel." Let's make it s/describing/& (as in "descriptive, not prescriptive")/. The lack of consensus (in the core kernel areas) is _not_ an invitation to pick a rule out of one's arse/nose/armpit/textbook/whatnot and stick it as The One True Style, and references to uniformity are worthless in such case. In particular, "whitespace before labels" kind of patches anywhere in VFS will be simply rejected. IMO what we need is to go through all rules in CodingStyle and if for some rule there is no overwhelming majority in the core kernel, well, the list has grown way too large and could use massive trimming.
