On Mon, Oct 07, 2013 at 12:28:26PM -0700, Joe Perches wrote: > On Mon, 2013-10-07 at 12:18 -0700, Josh Triplett wrote: > > The 80-character limit is not a hard-and-fast rule, nor should it be > > applied blindly by people running checkpatch and fixing its warnings. > > Sometimes it's better to violate the 80-character "limit" in the name of > > readability, and when it isn't, it's often better to refactor into a > > function or otherwise restructure the code rather than just finding > > increasingly awkward places to break lines. > > > > Thus, change checkpatch's LONG_LINE warning to a --strict CHK instead. > > Anyone wanting to use checkpatch to check for this can easily enough > > enable --strict or turn on LONG_LINE explicitly, but it shouldn't be > > part of the default warnings. > > I don't agree with this. > > CodingStyle says: > ---------------------- > The limit on the length of lines is 80 columns and this is a strongly > preferred limit. > ----------------------
Which is the subject of much controversy and extensive discussion, and the consensus on the list (including by many maintainers) frequently differs from that. > People should be encouraged to use 80 column lines and as well > should learn to ignore messages they don't agree with. I've seen far more examples of the 80-column limit making code less readable rather than more. It's only really helpful when it forces code restructuring, *not* when it just forces an arbitrary line break. > If people are using checkpatch prior to any scripted git am, > then just as easily they could add --ignore=LONG_LINE. Which random folks running checkpatch on staging drivers and trying to help don't necessarily know to do. The defaults should cater to the primary use case, and the 80-column limit is not something to apply blindly. It falls in the same category as some of the warnings the kernel emits with W=2 or so: sometimes helpful, often noise. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
