> 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: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
