I don't think anything has really changed since we had this discussion in 2015 [1]. Github and gerrit and IDEs existed then too, and we decided to leave it at 80 characters due to split screens and readability.
I personally still like 80 chars for these same reasons. [1] https://lists.apache.org/thread.html/3e1785cbbe14dcab9bb970fa0f534811cfe00795a8cd1100580f27dc@1430849118@%3Ccommon-dev.hadoop.apache.org%3E On Thu, Oct 20, 2016 at 7:46 AM, John Zhuge <jzh...@cloudera.com> wrote: > With HADOOP-13411, it is possible to suppress any checkstyle warning with > an annotation. > > In this case, just add the following annotation before the class or method: > > @SuppressWarnings("checkstyle:linelength") > > However this will not work if the warning is widespread in different > classes or methods. > > Thanks, > John Zhuge > > John Zhuge > Software Engineer, Cloudera > > On Thu, Oct 20, 2016 at 3:22 AM, Steve Loughran <ste...@hortonworks.com> > wrote: > > > > > > On 19 Oct 2016, at 14:52, Shane Kumpf <shane.kumpf.apa...@gmail.com> > > wrote: > > > > > > All, > > > > > > I would like to start a discussion on the possibility of removing the > > > package line length checkstyle rule (HADOOP-13603 > > > <https://issues.apache.org/jira/browse/HADOOP-13603>). > > > > > > While working on various aspects of YARN container runtimes, all of my > > > pre-commit jobs would fail as the package line length exceeded 80 > > > characters. While I'm all for automated checks, I feel checks need to > be > > > enforceable and provide value. Fixing the package line length error > does > > > not improve readability or maintainability of the code, and IMO should > be > > > removed. > > > > > > > I kind of agree here > > > > working on other projects with wider line lenghts (100, 120) means that > > you find going back to 80 chars so restrictive; and as we adopt java 8 > code > > with closures, your nesting gets even more complex. Trying to fit things > > into 80 char width often adds lots of line breaks which can make the code > > messier than if it need be. > > > > the argument against wider lines has historically been "helped > > side-by-side" patch reviews. But we have so much patch review software > > these days: github, gerrit, IDEs. i don't think we need to stay in > > punched-card width code limits just because it worked with a review > process > > of 6+ years ago > > > > > > > While on this topic, are there other automated checks that are > difficult > > to > > > enforce or you feel are not providing value (perhaps the 150 line > method > > > length)? > > > > > > > I like that as a warning sign of complexity...it's not a hard veto after > > all. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org > > > > >
