From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,8143b93889fe9472
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.180.82.1 with SMTP id e1mr26351wiy.1.1359686894682;
        Thu, 31 Jan 2013 18:48:14 -0800 (PST)
Path: 
 bp2ni9360wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.139.MISMATCH!xlned.com!feeder7.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newspeer1.nac.net!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!news.snarked.org!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!nuzba.szn.dk!pnx.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada standard and maximum line lengths
Date: Mon, 28 Jan 2013 15:28:44 +0200
Organization: Tidorum Ltd
Message-ID: <amncodFaek5U1@mid.individual.net>
References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com>
 <1mr198uopixbw$.c81fe8oczrwv.dlg@40tude.net>
 <7e0f4106-9a87-4602-9098-125e920d9d47@googlegroups.com>
 <510667a9$0$9504$9b4e6d93@newsspool1.arcor-online.net>
Mime-Version: 1.0
X-Trace: individual.net
 U4AOIrNFk1H5dFo2fjOjjw56QeuFdjO5upmrD7H7jzUUEJ3FNwhBwX9nZndPkTwimw
Cancel-Lock: sha1:PyUwiRTHSv2IXICOJpu6ZinfGkk=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
In-Reply-To: <510667a9$0$9504$9b4e6d93@newsspool1.arcor-online.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: 2013-01-28T15:28:44+02:00
List-Id: <comp.lang.ada>

On 13-01-28 13:57 , Georg Bauhaus wrote:
> On 28.01.13 11:02, Maciej Sobczak wrote:
>> I would not be surprised if the permission to limit is a leftover
>> from the ice age of line printers, without any real association
>> with today's systems.
> 
> Line lengths surely affect source code quality, and hence the way
> programmers can address tasks of ECRs etc. But how?  If automatic
> parsers can easily handle short lines or long lines, there is then
> more reason to emphasize why we do have lines in the first place!
> 
> I wonder what will be the effect on working in the programming
> profession of a general limit on line lengths that is, say, <= 100
> characters:

None for me. I am perfectly happy to write programs with at most 80
characters per line. If pressed, perhaps I can go up to 100.

But 200-character lines? How does one sensibly do a side-by-side diff,
for example?

> Will editing programs improve? If long lines are written in order to
> make the control structure more easily apparent (since indentation 
> then serves only the purpose of indicating control structure, no
> broken statements),

But breaking long statements into separate lines *helps* readability,
for example by placing each parameter for a call on its own line. And it
helps diffs, too (diffs are a very important part of version and change
tracking, for me at least).

For prose, narrow columns are known to be easier to read than page-wide
columns. The normal width of a book page is about the upper limit for me
-- any wider and my eyes lose track when doing "carriage return", so to
speak :-)

All hail the 80-column line!

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .