[moving to common-dev@] The 80 character limit is for legibility across dev environments. If it's impeding that goal in bash, then nobody will insist on it.
Since HADOOP-9902 rewrites most of this code, the particular cases can be worked through in that JIRA. -C On Sat, Jul 26, 2014 at 12:20 PM, Allen Wittenauer <a...@apache.org> wrote: > Hey folks: > > Deep linked by http://wiki.apache.org/hadoop/CodeReviewChecklist is the > rule that line length should be ideally maximum 80 chars. (Sun coding > guidelines.) In general, it's a good idea and it works for many many > languages... > > Now the caveat. > > As most of you know, I've been hacking on HADOOP-9902 off and on for a > year now. [For those that don't, this is an almost complete rewrite of > most of the major shell code that we ship with Hadoop. The stuff that was > missed I'll pick it up after this gets committed.] As part of this, I > recently reformatted the last patch to fit that 80 character requirement as > best I could. The result is... not good. Not good at all. In many ways, > it actually hurt readability even beyond the lack of indentation that Bash > Beautifier doesn't support for line continuation. (That case statement in > bin/hadoop is painful to look at and makes me cry.) > > Barring anymore feedback, it's pretty much ready to commit. But before > that happens, do we want to specify that bash has different line length > requirements? Say 120 chars? Most of the problems stem from our usage of > REALLY LONG env var names that can't really be changed at this point > without *massively* screwing backward compatibility. (Hello, > YARN_RESOURCEMANAGER_OPTS... I'm talking about you!). > > Bouncing the idea around a few folks, they all seem to agree that 80 is > just too hard for bash given our general use case, but I think it'd be good > to have something official. > > Thoughts? > > Thanks.
