hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Code guidelines and bash
Date Wed, 30 Jul 2014 10:46:25 GMT
one argument in favour of 80 is that it's easier to side-by-side diff

even so, I find it restrictive in Java code; once you go for long env vars
in bash-land then you are in trouble. As for python, you have to indent
according to your code flow.

were we to have a special getout of 120 chars in .sh, .py, and other
scripts, I'd be happy.




On 29 July 2014 18:59, Colin McCabe <cmccabe@alumni.cmu.edu> wrote:

> On Tue, Jul 29, 2014 at 2:45 AM, 俊平堵 <junping_du@apache.org> wrote:
> > Sun's java code convention (published in year of 97) suggest 80 column
> per
> > line for old-style terminals. It sounds pretty old, However, I saw some
> > developers (not me :)) like to open multiple terminals in one screen for
> > coding/debugging so 80-colum could be just fit. Google's java convention
> (
> >
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.4-column-limit
> )
> > shows some flexibility here with 80 or 100 column (and some exception
> > cases).
> > Like Chris mentioned early, I think this 80-column should just be a
> general
> > guideline but not a strict limit - we can break it if it hurts legibility
> > of code reading.
> > btw, some research work found that CPL (characters per line) only had
> small
> > effects on readability for news, including factors of speed and
> > comprehension (
> > http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp). Not
> > sure if reading code is the same (assume break lines properly).
>
> There is a lot of contradictory research in this area.  For example,
> http://eric.ed.gov/?id=EJ749012 talks about 70 characters per line as
> "ideal."
>
> I think a lot of these studies don't really translate very well to
> code.  (A lot of them are college students seeing how quickly they can
> read a news article.)  Code with extremely long line lengths tends to
> have super-deep nesting, which makes it hard to keep track of what is
> going on (the so-called "arrow anti-pattern").  This is especially
> true when there are break and continue statements involved.
> Super-long lines make diffs very difficult to do.  And it's just
> unpleasant to read, forcing users to choose between horizontal
> scrolling or tiny text...
>
> Maybe it makes sense to extend the bash line length, though, if it's
> tough to fit in 80 chars.  Bash is whitespace sensitive and doing the
> line continuation thing is a pain.  Another option might be renaming
> some variables, or using temp variables with shorter names...
>
> best,
> Colin
>
>
> >
> >
> > 2014-07-29 15:24 GMT+08:00 Andrew Purtell <apurtell@apache.org>:
> >
> >> On Mon, Jul 28, 2014 at 12:05 PM, Doug Cutting <cutting@apache.org>
> wrote:
> >>
> >> > On Sun, Jul 27, 2014 at 9:28 PM, Ted Dunning <tdunning@maprtech.com>
> >> > wrote:
> >> > > I don't know of any dev environments in common use today that can't
> >> > display >100 characters.
> >> >
> >> > I edit in an 80-column Emacs window that just fits beside an 80-column
> >> > shell window on a portrait-rotated 24" monitor.
> >> >
> >>
> >> You win the Internet today, Old School category! (smile)
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
>

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message