This discussion was split into two separate topics.
1) Remove line length checkstyle rule for package line
2) Remove line length checkstyle rule for the entire source code
1) I'm +1 for removing the rule for package line. I can provide a
trivial patch shortly in HADOOP-13603.
2) As Andrew said, the discussion was done in 2015. If we really want to
change the rule, we need to discuss again.
Regards,
Akira
On 10/21/16 07:12, Andrew Wang wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
