Re: Ada programs depend on fonts (was: aunit?)

Re: Ada programs depend on fonts (was: aunit?)

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
: I accept ACT's definition of "good style". Because to do otherwise
: takes more time than it is worth.

Hm. (For the same reason one could accept MSs definition of C++...)
Why does it take less time to transform source code into ACT style
than to obey one or more definitions of good style? (After all,
others might have good reasons for using a different good style and
that will likely lead to a bunch of programmers grimly reformatting
their sources :-)
But that is a matter of a source code _view_, see below, as in
to model-view-controller, or structure-and-form, or shape-and-content.

: Emacs, any fixed font. Of course :)
: 
: In general, I would recommend adapting the display tools to agree with
: the "standard" definition of good style (as defined by ACT, in this case).
 
There is some interesting evidence that looking at your program
in different shapes (for example on screen vs. carefully typeset)
will let you see things that you do not see if you look only at the on
screen version.  (The same might be true of more prose like text: you
see orthographical mistakes in one form of the text that you have not
seen in the other.)

I'm always annoyed by collegues relying on font colors, when they put /*
and */ and only these 4 characters around some larger portion of source
code. They say they can easily see that this part of the program is
ineffective, because it appears in a color for comments.  (At least Ada
defeats this problem.) To me, this seems less likely to happen if people
don't make their programming depend so much on font choice etc.

:> (consider f (x) in most various circumstances.) Seen this way one
:> might argue that -gnaty is completely unaware of any typographical
:> tradition in mathematical typesetting. 
: 
: Ada source code is not meant to be typeset; that's what LaTeX is for. 

Depends. It might increase quality. Then, there is also Ada letters.

:> It seems to be aware of typical font appearance in typical plain
:> text editors, 
: 
: Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font
: in bitmapped displays".

Emacs is a sophisticated plain text editor, aware of a number of
syntax rules for plain text. Editing Plain text, including editing program
text, is complicated and Emacs can help a lot knowing the syntax rules
of the plain text. (That implies syntax directed plain text navigation,
and there are a few Emacs major modes that are excellent in this respect.)
Ada source code is just plain text. No fancy formatting,
no fonts, no colors. Ada compilers don't handle fonts and colors
(note the omission of formatting, because of front ends aware
of indentation).
A view of Ada source code might have fonts and colors, but should programs
be written in a way that is largely influenced by one view
of source code? I think not.


:> on typical low res displays, 
: 
: 1280 by 1024; I don't think that counts as "low res".

But it is low resolution, as long as the resolution isn't around
some 400 dpi. What counts is the number of pixels per visible stretch,
the shape of pixels, and, if applicable, the resolution of a font.
That does not necessarily have anything to do with the number of pixels
of a device.
 
:  picking a good fixed with font is critical. But I've done that.

I hope it's not mission critical? :-)
 
:> I wish one could ask -gnatyX to concentrate on those aspects of
:> source code which render Ada text ambigous to the human eye, like
:> using l near 1 (or using l at all. Isn't there a "k instead of i in
:> GNAT" policy?).
: 
: Again a matter of good font choice; no excuse for using a font in
: which 1 (one) and l (letter ell) are confused.

Well, I'd rather say, no excuse for making source code depend on
font choice. You have given hints in 2 paretheses, presumably because
you know that different news reading software might display 1 and l 
differently?
Who is going to maintain the program text in which IDE using what
font? Yours in both respects? Source code maintenance shouldn't be a
matter of choosing good font choice, should it?


-- Georg
(require 'ada-mode)

Re: Ada programs depend on fonts (was: aunit?)

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> : I accept ACT's definition of "good style". Because to do otherwise
> : takes more time than it is worth.
> 
> Hm. (For the same reason one could accept MSs definition of C++...)

Touche :).

> Why does it take less time to transform source code into ACT style
> than to obey one or more definitions of good style? 

The point is for the entire Ada community to have exactly _one_
definition of good style, and _always_ use it. Then it is always
faster to convert everything to that _one_ style, or to simply write
in that style in the first place.

> (After all, others might have good reasons for using a different
> good style and that will likely lead to a bunch of programmers
> grimly reformatting their sources :-) 

Yes, there are often "good reasons" for picking one style over
another. But they are all swamped by the overwhelming advantage of
simply using _one_ style.

> But that is a matter of a source code _view_, see below, as in to
> model-view-controller, or structure-and-form, or shape-and-content.

Yes, you can use tools to present different views.

> : Emacs, any fixed font. Of course :)
> : 
> : In general, I would recommend adapting the display tools to agree with
> : the "standard" definition of good style (as defined by ACT, in this case).
>  
> There is some interesting evidence that looking at your program
> in different shapes (for example on screen vs. carefully typeset)
> will let you see things that you do not see if you look only at the on
> screen version.  (The same might be true of more prose like text: you
> see orthographical mistakes in one form of the text that you have not
> seen in the other.)

Interesting. I don't have much experience with looking at code other
than in Emacs (or equivalent), so I can't really comment.

> I'm always annoyed by collegues relying on font colors, when they put /*
> and */ and only these 4 characters around some larger portion of source
> code. They say they can easily see that this part of the program is
> ineffective, because it appears in a color for comments. 

That feature of Emacs has saved me many times when reading C code. I
agree it's not good; that's one reason I use Ada :).

> (At least Ada defeats this problem.) To me, this seems less likely
> to happen if people don't make their programming depend so much on
> font choice etc.

No, the font choice is a reasonable fix for a bad language design
combined with bad programming style. What alternate fix would you
propose? Hmm, I guess you could require /* */ on each line; Emacs does
that when you ask it to comment out a block.

> :> (consider f (x) in most various circumstances.) Seen this way one
> :> might argue that -gnaty is completely unaware of any
> :> typographical tradition in mathematical typesetting.
> : 
> : Ada source code is not meant to be typeset; that's what LaTeX is for. 
> 
> Depends. It might increase quality. Then, there is also Ada letters.
> 
> :> It seems to be aware of typical font appearance in typical plain
> :> text editors, 
> : 
> : Hmph. Emacs is _not_ a plain text editor :). I would say "fixed font
> : in bitmapped displays".
> 
> Emacs is a sophisticated plain text editor, aware of a number of
> syntax rules for plain text. Editing Plain text, including editing program
> text, is complicated and Emacs can help a lot knowing the syntax rules
> of the plain text. (That implies syntax directed plain text navigation,
> and there are a few Emacs major modes that are excellent in this respect.)
> Ada source code is just plain text. No fancy formatting,
> no fonts, no colors. 

I think we are trying to define the term "plain text"; you seem to be
saying "fonts and colors is not plain text". Since Emacs can display
Ada code using fonts and color, it is not a "plain text" editor.

Another way to look at it; in the beginning, Emacs only worked with
character cells; that's a good definition of "plain text". But with
version 21, Emacs can deal with arbitrary bitmapped displays, so it
really is no longer a "plain text" editor.

> Ada compilers don't handle fonts and colors (note the omission of
> formatting, because of front ends aware of indentation). 

That's true; Ada compilers do require "plain text" input.

> A view of Ada source code might have fonts and colors, but should
> programs be written in a way that is largely influenced by one view
> of source code? I think not.

I agree that the semantics of a program should not be determined by
the view (one reason I don't like Python; indentation determines
semantics!). But the user process of writing that code can benefit
from a good view (fonts and colors).

> :> on typical low res displays,
> : 
> : 1280 by 1024; I don't think that counts as "low res".
> 
> But it is low resolution, as long as the resolution isn't around
> some 400 dpi.

Ok; that's a meaningful definition.

> What counts is the number of pixels per visible stretch, the shape
> of pixels, and, if applicable, the resolution of a font. That does
> not necessarily have anything to do with the number of pixels of a
> device.

Ok.

> :  picking a good fixed with font is critical. But I've done that.
> 
> I hope it's not mission critical? :-)
>  
> :> I wish one could ask -gnatyX to concentrate on those aspects of
> :> source code which render Ada text ambigous to the human eye, like
> :> using l near 1 (or using l at all. Isn't there a "k instead of i in
> :> GNAT" policy?).
> : 
> : Again a matter of good font choice; no excuse for using a font in
> : which 1 (one) and l (letter ell) are confused.
> 
> Well, I'd rather say, no excuse for making source code depend on
> font choice. You have given hints in 2 paretheses, presumably because
> you know that different news reading software might display 1 and l 
> differently?

Exactly; I have zero control over your newsreader. But I have total
control over the software development process used on my projects, and
I can easily require a proper font.

> Who is going to maintain the program text in which IDE using what
> font? Yours in both respects? 

Yes.

> Source code maintenance shouldn't be a matter of choosing good font
> choice, should it?

That's part of it, yes. Just as I have to specify what config
managment tool to use, and what backup tool to use, I can specify what
font makes the code readable. The font choice is less important, but
in the same category of "things I have control over, and therefore
should specify".

-- 
-- Stephe

Re: Ada programs depend on fonts (was: aunit?)

[David C. Hoos]

Has anyone compared the GNAT style to the
Ada 95 Quality and Style Guide:
Guidelines for Professional Programmers
available at:
http://adaic.org/docs/95style/

This style guide covers a lot more than code presentation
(which is all that the GNAT style enforces).  It covers such
equally-important subjects as naming conventions, concurrency,
portability, performance, and a lot more.

It also provides a rationale for each of its guidelines -- guidelines
which, if followed, would produce more-readable, more-maintainable,
and better-performing Ada programs.

Just my $0.02 worth.

----- Original Message -----
From: "Stephen Leake" <Stephe.Leake@nasa.gov>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Thursday, April 17, 2003 12:19 PM
Subject: Re: Ada programs depend on fonts (was: aunit?)


<snip>
> The point is for the entire Ada community to have exactly _one_
> definition of good style, and _always_ use it. Then it is always
> faster to convert everything to that _one_ style, or to simply write
> in that style in the first place.
>
<snip>

Re: Ada programs depend on fonts (was: aunit?)

[Leon Winslow]

I agree but with one addition.  The great majority of the guidelines apply
to almost any third generation language, not just to Ada.  Furthermore,
reading the justifications give students a better feel for good
programming in genral.

For these reasons I have often made it required in many of my classes.

Lee Winslow

"David C. Hoos" wrote:

> Has anyone compared the GNAT style to the
> Ada 95 Quality and Style Guide:
> Guidelines for Professional Programmers
> available at:
> http://adaic.org/docs/95style/
>
> This style guide covers a lot more than code presentation
> (which is all that the GNAT style enforces).  It covers such
> equally-important subjects as naming conventions, concurrency,
> portability, performance, and a lot more.
>
> It also provides a rationale for each of its guidelines -- guidelines
> which, if followed, would produce more-readable, more-maintainable,
> and better-performing Ada programs.
>
> Just my $0.02 worth.
>
> ----- Original Message -----
> From: "Stephen Leake" <Stephe.Leake@nasa.gov>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: Thursday, April 17, 2003 12:19 PM
> Subject: Re: Ada programs depend on fonts (was: aunit?)
>
> <snip>
> > The point is for the entire Ada community to have exactly _one_
> > definition of good style, and _always_ use it. Then it is always
> > faster to convert everything to that _one_ style, or to simply write
> > in that style in the first place.
> >
> <snip>

Re: Ada programs depend on fonts

[Georg Bauhaus]

David C. Hoos <david.c.hoos.sr@ada95.com> wrote:
: http://adaic.org/docs/95style/
 
: [...] -- guidelines
: which, if followed, would produce more-readable, more-maintainable,
: and better-performing Ada programs.
: 
: Just my $0.02 worth.

The decimal point should appear a few places to the right of
these digits :-)