TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To: Niklas Holsti <[log in to unmask]>
Date: Tue, 2 Sep 2003 09:54:11 -0400
Reply-To: Stephen Leake <[log in to unmask]>
From: Stephen Leake <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Parts/Attachments: text/plain (50 lines)
Niklas Holsti <[log in to unmask]> writes:

> On Fri, Aug 29, 2003 at 12:52:08PM -0400, Stephen Leake wrote:
> > Ada is a "tool for the next century"; let's not carry the "support
> > legacy stuff" too far. There's no excuse for a line length limit of
> > less than 120.
>
> I disagree with that rather dogmatic statement.

It is a bit dogmatic. Good for promoting discussion :). Although I
suppose this discussion would be better held on comp.lang.ada; this
mailing list is supposed to be about promoting Ada.

Hmm. If most developers in other languages use a line length limit of
80, then using 120 for Ada would discourage those developers from
switching. Now we're back on topic :).

> It is true that text files with 120 characters/line are no problem
> as such, but I have found "sdiff" to be a very useful and important
> tool for me. With lines up to 80 characters long, it is just about
> possible to get a readable "sdiff" listing in a window of width
> around 165 characters.

Ok, you have a tool that works better with an 80 character line limit.
In general, I accept that as a good rationale.

However, in this case, I suggest a better tool; Gnu Emacs ediff. It
displays the two files in two windows, one over the other. Then it
uses color to highlight the differences, down to the word. Very easy
to read. And it works with long line lengths.

> It helps that I indent calls in the style
>
>   Procedure_Name (
>      Par1 => Val1,
>      Par2 => Val2);
>
> and not as
>
>   Procedure_Name (Par1 => Val1,
>                   Par2 => Val2);
>
> which in my eyes make the code look very irregular, since the length
> of procedure names varies.

I agree on this indentation style.

--
-- Stephe

ATOM RSS1 RSS2