Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of cembree@gmail.com designates
 209.85.223.176 as permitted sender)
MIME-Version: 1.0
Reply-To: chris@embree.us
In-Reply-To: 
 <CAE7-c1axadMb0EAoVK8rSRxpE0FZqUj36wBwZTbhT5HihKHYxA@mail.gmail.com>
References: 
 <CAH3-CVz+0QU8omZR3nQ2HKC4Lf5WQ8==Vo8KDA+8+HQwCA-V0A@mail.gmail.com>
	<CAE7-c1axadMb0EAoVK8rSRxpE0FZqUj36wBwZTbhT5HihKHYxA@mail.gmail.com>
Date: Sat, 26 Jul 2014 22:29:06 -0400
Message-ID: 
 <CADokdcOkto87=HNznzoTPatFTOhoiLJiBZHC=t07g6+k5F9mHg@mail.gmail.com>
Subject: Re: Code guidelines and bash
From: Chris Embree <cembree@gmail.com>
To: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=20cf30223e5319f3b404ff239208

--20cf30223e5319f3b404ff239208
Content-Type: text/plain; charset=UTF-8

Allen, et. al.,

I'm not sure how up to date that checklist is, but imposing such a small
size on cmd arguments seems incredibly short sighted.  I'm pretty sure that
it is not a generally accepted limit.  I've seen MANY Hadoop processes
require lengthy CLASS_PATHS that were easily over 240 chars.

BTW, the BASH limit is something around 24k, well beyond 120 chars.

IMHO, if you want to avoid Bill Gates syndrome, (no one will ever need more
than 256k RAM) you might want to set an upper limit around 64K.   And then
I'd use a configuration file so I could be stupid and request a max of
256M, because I'm doing something way abnormal.

$0.02.  YMMV. ;)


On Sat, Jul 26, 2014 at 10:02 PM, Paresh Yadav <pyadav@hortonworks.com>
wrote:

> Hey Allen,
>
> I am not a shell scripting expert but I have written few and used/seen many
> from including top 3 enterprise software giants. I don't think everyone
> sticks to 80 char guidelines, may be this is remnant of the old 80 char
> terminals. I prefer long descriptive names for the env vars (or vars in
> general) as it makes the program more readable. Not sure what are technical
> ramifications of having lines longer than 80 char if any.
>
> *Thanks,*
> Paresh Yadav
> Solutions Engineer, Canada
>
> Phone:     416.688.1003
> Email:      pyadav@hortonworks.com
> Website:   http://www.hortonworks.com/
>
> *Follow Us: *
> <
> http://facebook.com/hortonworks/?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature
> >
>
> <
> http://twitter.com/hortonworks?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature
> >
> <
> http://www.linkedin.com/company/hortonworks?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature
> >
>
> [image: photo]
>
>
> On Sat, Jul 26, 2014 at 3:20 PM, Allen Wittenauer <aw@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.
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

--20cf30223e5319f3b404ff239208--