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
>
>

Reply via email to