Code Formatters

Code Formatters

[Dave Smith]

I know it`s an old old question but are there any decent
code formatters for Ada. I`m aware of Ada Assured from
a company called Grammatech, anyone out there have any
experience of it?

I personally can't stand code formatters as a matter of
principal, they just make coders lazy.

Anyway, if anyone has any views, let me know.

Many Thanks

Dave Smith
Chief Software Engineer
GMCS

Re: Code Formatters

[Frank C. Post]

We had Meridian's Ada compiler for a long time, and it came packaged with
AdaForm.  However, I'm sure that the formatter was not dependant upon the
Meridian environment.  It was an ok product whcih had a decent selection of
switches that could be used to control indentation, capitalization, etc. 
Maybe Meridian (or Alsys or Thomson) has it available as standalone.

--postman

Re: Code Formatters

[Mike Stark]

Dave Smith wrote:
> 
> I know it`s an old old question but are there any decent
> code formatters for Ada. I`m aware of Ada Assured from
> a company called Grammatech, anyone out there have any
> experience of it?
> 
> I personally can't stand code formatters as a matter of
> principal, they just make coders lazy.

I completely disagree -- we shouldn't be paying software developers to
worry about whether the indentation is two or three spaces, or whether
the "record" keyword should be on the same line or the next line as the 
"type" keyword.  We're paying people to think, not to format.
> 
> Anyway, if anyone has any views, let me know.
> 
I think I just did! :)

Mike

> Many Thanks
> 
> Dave Smith
> Chief Software Engineer
> GMCS

Re: Code Formatters

[Robert Dewar]

Mike Stark says

"I completely disagree -- we shouldn't be paying software developers to
worry about whether the indentation is two or three spaces, or whether
the "record" keyword should be on the same line or the next line as the
"type" keyword.  We're paying people to think, not to format."

This is like saying that we shouldn't be paying novelists to write correct
grammar or elegant style, they should just be thinking aout plots, and
copy editors will fix things up.

In fact the only kind of software engineers that I would be willing to pay
are those who DO worry about the style of their code, and take some pride
in laying it out and documenting it in an elegant manner.

Thinking that automatic formatting programs can convert junk code to
elegant code, particularly with respect to laying out comments nicely,
is like those who in the 60's thought that they could replace docuemtnation
by automatic flow chart generators.

Re: Code Formatters

[Robert Dewar]

Ole-Hjalmar says

"Your idea of elegant code may not coincide with mine. As a project
leader, I want *standardized* layout. Having a standard layout
which is conformant to the output to some prettyprinter is in my
opinion a good idea, because it means that those who do not want to be
burdened with the detailed layout can avoid it. This does not stop
anyone from documenting the program in an elegant manner, assuming
that you can stop the prettyprinter from mangling your comments."

I don't accept this attitude. It is important for a team working together
on a product to agree on a concept of elegant style. Otherwise you get
a situation where people do not like to work on other people's programs.

Note that your model requires an unpretty printer, and that is much harder.
Consider

programmer A thinks the standard style is nuts, and does his or her own thing.
The code that A generates is fed into a pretty printer to check into the
configuration management system.

Now, what does A do? Work with the checked in version, cerainly not, it's
in unacceptable junk style, so they keep a mirror in what they consider
"proper" style.

Now here's where the problem comes in, programmer B wants to modify that
same file. What do they do? Work on the checked in version? But now that
means that programmer A refuses to work with the result! Work with the
mirror? But that is in some (to them) horrible style.

The model where everyone uses there own style leads to a notion of code
ownership that is inimical to large projects. I worked in one large 
company (the name would amuse you, but should be kept private I think),
where a critical component of the software was written in a private style
with Mixed_Case_Identifiers_With_Some_ACRONYMS_In_Upper_Case. The company
style was ALL_UPPER_CASE. Now you can pretty print the first into the
second, but you cannot go backwards. The result was that this component
was the private property of this one guy, and when he left, the code was
an unknown mystery.

This is not an uncommon situation.

In the GNAT project, we take a totally different approach. We discuss
style, and where there is a disagreement, we just vote, and take the
simple majority input. There is some horse-trading in setting up the
agreements, so that hopefully no one, at least no one who was originally,
involved feels too left out. Then the minority changes. The change can be
painful (as I have mentioned in the past, I found it hard to change
from SHOUTING_IDENTIFIERS to Mixed_Case, but you get used to everything).
Similarly people coming onto the project later often complain at first,
but people adapt, and this adaptation is just something that we insist on.

The result is an environment in which there is very little sense of code
ownership, and anyone who knows how can modify any unit in the system (we
have an elaborate regression testing scheme to make sure that people cannot
introduce regressions as they do such modifications).

This leads to a much more productive and cooperative environment, and, most
importantly, there is almost no code that is understood by only one person.

P.S. Sure, I have done a lot of COBOL programming, and you get used to
any style. For example, in COBOL, even when writing non-typical COBOL
code (I wrote a big chunk of the Realia COBOL compiler, now marketed
by Computer Associates, and that compiler is 100% in COBOL), I adopted
the COBOL style, and preferred IS GREATER THAN to >. As I say, style is
really what you are used to.

Another advantage of standardized style is that people throughout the
Ada community can more easily read one another's code. There is nothing
in C that stops you using the ALL_UPPER_CASE style for identifiers, but
C programmers will find your programs (a) ugly and (b) hard to read.
Similarly in Ada, there is nothing that stops you from using Mike Feldman's
all upper case keyword style, but most Ada programmers will find the 
resulting programs (a) ugly and (b) hard to read.

As for tools, yes, of course, it is useful to have tools to help with minor
style issues, preferably ones that guide you as you do the original creation
of the source, such as the Ada mode in EMACS. I personally prefer not to
use any such tools, I am a fast typist and I find that any molestation of
the source as I enter it slows me down, but many other peoplee, including
some people on the GNAT team could not live without EMACS Ada mode. That's
a personal choice. The critical thing is that everyone can read everyone
elses code, and work with it easily, how that code is produced is not
critical, but the idea of using code formatters to achieve this kind of
interchange simply does not work.

Re: Code Formatters

[Larry Kilgallen]

In article <dewar.847201701@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> In the GNAT project, we take a totally different approach. We discuss
  ^^^^^^^^^^^^^^^^^^^
> style, and where there is a disagreement, we just vote, and take the
> simple majority input.

Easy.

> Another advantage of standardized style is that people throughout the
                                                         ^^^^^^^^^^^^^^
> Ada community can more easily read one another's code.
  ^^^^^^^^^^^^^

Hard.

Those who want to change the style of something they did not write
are forced to provide a converter, but only when they provide it to
another (such as by checking it in) can styles be enforced, such as
by noticing that Channels_For_CBS _or_ Channels_For_CBs _both_ change
to Channels_For_Cbs which does not match the original (in either case).

Larry Kilgallen

Re: Code Formatters

[Robert Dewar]

Larry said

"> Another advantage of standardized style is that people throughout the
                                                         ^^^^^^^^^^^^^^
> Ada community can more easily read one another's code.
  ^^^^^^^^^^^^^

Hard."

Well, sure, hard in general, but at least for identifier capitalization,
there is something approaching a consensus.
\x1a

Re: Code Formatters

[John English]

Philip Brashear (brashear@ns1.sw-eng.falls-church.va.us) wrote:
: In article <dewar.847124036@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: >In fact the only kind of software engineers that I would be willing to pay
: >are those who DO worry about the style of their code, and take some pride
: >in laying it out and documenting it in an elegant manner.

: Right on, Robert!
: That's why I drive my Ada students (at the University of Dayton) absolutely
: NUTS by talking so much about style, readability, etc.

I always tell my students that the compiler is far more forgiving
about layout than I am: "If I can't read it, I won't mark it".

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------

Re: Code Formatters

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <dewar.847124036@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   Mike Stark says

   "I completely disagree -- we shouldn't be paying software developers to
   worry about whether the indentation is two or three spaces, or whether
   the "record" keyword should be on the same line or the next line as the
   "type" keyword.  We're paying people to think, not to format."

   This is like saying that we shouldn't be paying novelists to write correct
   grammar or elegant style, they should just be thinking aout plots, and
   copy editors will fix things up.

Yes, I agree, but only to a certain extent. When you write a report,
do you use hours fiddling with fonts, margins, etc. on a wysiwyg
editor, or do you describe the structure of the document and let
something like Tex/Latex take care of the details? Certainly, those
tasks which can be done more efficiently by the computer should be
done that way.

   In fact the only kind of software engineers that I would be willing to pay
   are those who DO worry about the style of their code, and take some pride
   in laying it out and documenting it in an elegant manner.

Your idea of elegant code may not coincide with mine. As a project
leader, I want *standardized* layout. Having a standard layout
which is conformant to the output to some prettyprinter is in my
opinion a good idea, because it means that those who do not want to be
burdened with the detailed layout can avoid it. This does not stop
anyone from documenting the program in an elegant manner, assuming
that you can stop the prettyprinter from mangling your comments. In my
experience, this is not much of a problem, unless you insist on very
arcane commenting styles.

   Thinking that automatic formatting programs can convert junk code to
   elegant code, particularly with respect to laying out comments nicely,
   is like those who in the 60's thought that they could replace docuemtnation
   by automatic flow chart generators.

We are not talking about converting junk code, but about avoiding
unnecessary work which could be done by a program.

Re: Code Formatters

[Philip Brashear]

In article <dewar.847124036@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>In fact the only kind of software engineers that I would be willing to pay
>are those who DO worry about the style of their code, and take some pride
>in laying it out and documenting it in an elegant manner.

Right on, Robert!
That's why I drive my Ada students (at the University of Dayton) absolutely
NUTS by talking so much about style, readability, etc.

If the code is not reasonably formatted, then it's difficult to read, hence
difficult to understand; hence difficult to get right (not to mention that
minor activity called "maintenance")!

Phil Brashear

Re: Code Formatters

[Marin David Condic, 561.796.8997, M/S 731-93]

Philip Brashear <brashear@NS1.SW-ENG.FALLS-CHURCH.VA.US> writes:
>If the code is not reasonably formatted, then it's difficult to read, hence
>difficult to understand; hence difficult to get right (not to mention that
>minor activity called "maintenance")!
>
    This is all true, but there's another factor to consider. The
    programmer who is obsessive-compulsive enough to go back over the
    code, space everything properly, correct the character case of
    everything, get the indenting right, etc. etc. is also going to be
    the one who is double checking all the logic as well. Some of it
    is by virtue of simply reviewing the code - you notice more
    mistakes. Some of it is by individual mindset. If you're careful
    enough to get the purely superficial things correct in every
    detail, you are more likely to be the one agonizing over getting
    all the fundamental things correct as well.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Outside of a dog, a book is man's best friend; inside a dog,
    it's too dark to read..."

        --  Groucho Marx
===============================================================================

Re: Code Formatters

[Dave Smith]

As I seem to have started off a good old fashioned discussion on
the rights and wrongs of standards formats, let me add another
tw'pence worth.

Surely what we need are decent development environments with
good language sensitive editors. These should be able to read
a file containing the "rules" to be used for layout, the indenting,
capitalization, etc. being done as the code is typed in. 

Or maybe it would have been useful to have included the Ada
Style Guide (the "bible" as far as I am concerned) as part of
the ANSI standard. Them we would all have code that conformed to
the same layout.

To me, the reasons for having a standard layout are:

1) Coders don't need to think how to layout the code, and so
   can get on with the coding.

2) It's easier to read someone else`s code.

3) Having a standard layout makes it easier to give the code
   listings to the customer. The last thing I want to do is to
   send a customer the listings for ten packages all using a
   different style.

BTW

Thanks to Robert Dewar for getting involved in this thread...
"We are not worthy!"

Dave Smith
Chief Software Engineer
GEC-Marconi S3I
Combat Systems Division
Addlestone
England

Re: Code Formatters

[Mike Stark]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:
> 
> In article <dewar.847124036@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
>    Mike Stark says
> 
>    "I completely disagree -- we shouldn't be paying software developers to
>    worry about whether the indentation is two or three spaces, or whether
>    the "record" keyword should be on the same line or the next line as the
>    "type" keyword.  We're paying people to think, not to format."
> 
>    This is like saying that we shouldn't be paying novelists to write correct
>    grammar or elegant style, they should just be thinking aout plots, and
>    copy editors will fix things up.

No, Robert, what I am really saying is that a novelist shouldn't have to
worry about
page layout and fonts.  I think by disagreeing "completely" I obscured
the distinction
(and there is one, in my IMHO) between "formatting" and "programming
style".  The
former is an area that is properly left to tools (if you can find one
that will
do what you want -- at NASA we use acronyms heavily, so we like variable
names
such as "IRU_Measurement_Partials" instead of 
"Inertial_Reference_Unit_Partial_Derivatives").  Programming style of
course, should be as Robert says -- correct and elegant.

> 
> Yes, I agree, but only to a certain extent. When you write a report,
> do you use hours fiddling with fonts, margins, etc. on a wysiwyg
> editor, or do you describe the structure of the document and let
> something like Tex/Latex take care of the details? Certainly, those
> tasks which can be done more efficiently by the computer should be
> done that way.
> 
>    In fact the only kind of software engineers that I would be willing to pay
>    are those who DO worry about the style of their code, and take some pride
>    in laying it out and documenting it in an elegant manner.

I agree in the case of programming style.  The problem on formatting is
that there
is more than one elegant manner, and projects want code to read
consistently.  This
to me is where tools come in -- to give the delivered code a
*consistent* style as
well as an *elegant* one.
> 
> Your idea of elegant code may not coincide with mine. As a project
> leader, I want *standardized* layout. Having a standard layout
> which is conformant to the output to some prettyprinter is in my
> opinion a good idea, because it means that those who do not want to be
> burdened with the detailed layout can avoid it. This does not stop
> anyone from documenting the program in an elegant manner, assuming
> that you can stop the prettyprinter from mangling your comments. In my
> experience, this is not much of a problem, unless you insist on very
> arcane commenting styles.
> 
>    Thinking that automatic formatting programs can convert junk code to
>    elegant code, particularly with respect to laying out comments nicely,
>    is like those who in the 60's thought that they could replace docuemtnation
>    by automatic flow chart generators.

This is not at all what I was thinking.  I don't really want to go
beyond maintaining
that we don't pay software developers to worry about whether standard
indentation is
two, three, or four characters.
> 
> We are not talking about converting junk code, but about avoiding
> unnecessary work which could be done by a program.

Mike

Re: Code Formatters

[Larry Kilgallen]

In article <55q621$v6s@gcsin3.geccs.gecm.com>, Dave Smith <david.h.smith@gecm.com> writes:

> Surely what we need are decent development environments with
> good language sensitive editors. These should be able to read
> a file containing the "rules" to be used for layout, the indenting,
> capitalization, etc. being done as the code is typed in. 

Another dimension is syntax coloring.  If an editor can be set to
do _only_ syntax coloring someone gets aid dealing with code but
does not automatically disturb placement.

BBEdit seems likely to get syntax coloring for Ada, which to me
is actually more significant than the same for an editor provided
with an Ada compiler, where one would expect such support.  Also
I would prefer editors from people devoted to editors as they will
likely do a better job for cut and paste, etc.

LSE on VMS of course has done Ada for years, although I do not
use it because I have another favorite editor on VMS. DEC did
Ada 83, of course, but those templates can be updated for Ada 95
by anyone who cares to do so.

Larry Kilgallen

Re: Code Formatters

[Robert Dewar]

Dave Smith says

"Or maybe it would have been useful to have included the Ada
Style Guide (the "bible" as far as I am concerned) as part of
the ANSI standard. Them we would all have code that conformed to
the same layout."

Dubious -- first, you could never have got agreement on a specific set
of rules. Second, and perhaps more important, a good set of style
guidelines is just that, a set of guidelines, not absoulute rules,
and many of them are occasionally broken for good reasons.

For example, in the GNAT world, we enforce the -gnatf set of
rules, oops, I mean -gnatg, with the compiler considering violations
to be errors (for details, have a look at style.adb i the GNAT sources).

But the GNAT style involves MANY other rules that are not enforced
mechanically (they are mostly enforced by self discipline, and then
I check all checkins to make sure they meet the style rules, early
on I used to find many deviations, now everyone really knows the rules
and there is rarely need for correction, but that does not mean that
these style reuls are oebyed 100%

Re: Code Formatters

[Axel Boness]

In article <dewar.847201701@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
|>Ole-Hjalmar says
|>
|>"Your idea of elegant code may not coincide with mine. As a project
|>leader, I want *standardized* layout. Having a standard layout
|>which is conformant to the output to some prettyprinter is in my
|>opinion a good idea, because it means that those who do not want to be
|>burdened with the detailed layout can avoid it. This does not stop
|>anyone from documenting the program in an elegant manner, assuming
|>that you can stop the prettyprinter from mangling your comments."
|>


I totally agree with you. Here we have thousands of units of code which
were written (and maintened) by about 80 different developpers. Each had
his own style of formatting. Readability is good because people took
care when writting the code. But styles are different and when one is
maintening the code he has to browse in different styles loosing time to
understand how the code is formatted.

Therefore I would like to work with a language where presentation is
normalised  (enforced by the editor) even if it's not as beautifull as
it may be.

 
-------------------------------------------------------------------
Axel Boness

http://www.anywhere.com/standard_disclaimer.html

Tel : (33) 4 76 41 46 00 (4811)        Fax : (33) 4 76 41 47 47
E-Mail : Axel.Boness@Sema-Grenoble.fr

Re: Code Formatters

[Robert Dewar]

Axel says

"Therefore I would like to work with a language where presentation is
normalised  (enforced by the editor) even if it's not as beautifull as
it may be."

Well that's a bit inconsistent, do you mean enforced by the language, as
implied by your first phrase, or enforced by the tools you are using (in
which case it has nothing to do with the language).

For a *language* that enforces style, COBOL comes closest probably, but
still leaves LOTS unsaid, and extensive coding standards are still needed.
I know of no *language* so tightly defined as to make auxiliary style
guidelines unnecessary.

Whatever language you are using, you need to work in an environment where
there are clear style rules that are consistently followed.

There are many ways of enforcing such rules (threat of firing people, social
pressure, job evaluation in genral, automatic editing tools, automatic
formatting tools, checks in the compiler etc.)

Of these, I prefer checks in the compiler (as we use in GNAT, with -gnatg)
but these are seldome more than very simple issues. I personally don't
like any editor that messes with me in any way (I hate templates or any
kind of on the fly fixup of what I type), but others really like editors
that help out (e.g. Ada mode in EMACS).

Re: Code Formatters

[Robert Dewar]

Larry says

"BBEdit seems likely to get syntax coloring for Ada, which to me
is actually more significant than the same for an editor provided
with an Ada compiler, where one would expect such support.  Also
I would prefer editors from people devoted to editors as they will
likely do a better job for cut and paste, etc."

Note of course that EMACS also provides Ada coloring mode, as well as
lots of other helpful stuff.

Re: Code Formatters

[Simon Wright]

Dave Smith <david.h.smith@gecm.com> writes:

> Surely what we need are decent development environments with
> good language sensitive editors. These should be able to read
> a file containing the "rules" to be used for layout, the indenting,
> capitalization, etc. being done as the code is typed in. 

The old Rational Environment looked like this, to the user. I'm not
sure if it was even possible to write eg Text_IO! I'm not familiar
with APEX, perhaps it works similarly?

Of course, any help is welcome (eg, emacs ada-mode).

But I strongly agree with the person who wrote that the programmer who
cares enough to get the surface details right is likely to care about
the deeper aspects too. I tend to look at it the other way round; if
he doesn't care what his work looks like, why should I suppose he
cares about what it does?

-- 
Simon Wright                    Work Email: simon.j.wright@gecm.com
Ferranti Naval Systems                     Voice: +44(0)1705-701778
GEC-Marconi S3I Combat Systems Division      FAX: +44(0)1705-701800

Re: Code Formatters

[Axel Boness]

In article <dewar.847456987@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
|>Axel says
|>
|>"Therefore I would like to work with a language where presentation is
|>normalised  (enforced by the editor) even if it's not as beautifull as
|>it may be."

I meant "enforced by the language". I deeply apologise not to have
reread my posting before submitting it. It took me a lot of time to
write the posting because english is not my mother tongue, and I didn't
give myself time to reread (well I have to work from time to time :-).

|>For a *language* that enforces style, COBOL comes closest probably, but
|>still leaves LOTS unsaid, and extensive coding standards are still needed.
|>I know of no *language* so tightly defined as to make auxiliary style
|>guidelines unnecessary.

There are two major kinds of rules:
1) presentation (I mean indentation, line size, relative position of
keywords, ...)
2) programming style (choice of the identifier (size and meaning), volume
of the comments, size of the subprograms...)

Type 1) rule may be clearly expressed even if the result of
applying these rules is not always good looking. There are always
pathological cases.
Type 2) rule are part of the programming activity and are personnal to
each developper even if it's possible to give bounds with programming
rules (like those in the Ada style guidebook).

|>Of these, I prefer checks in the compiler (as we use in GNAT, with -gnatg)
|>but these are seldome more than very simple issues. I personally don't
|>like any editor that messes with me in any way (I hate templates or any
|>kind of on the fly fixup of what I type), but others really like editors
|>that help out (e.g. Ada mode in EMACS).

I do have problems with such editors. But if it's the price to pay to
have homogeneous code (I mean presentation), I'm willing to pay, if it's
"universal".

-------------------------------------------------------------------
Axel Boness

http://www.anywhere.com/standard_disclaimer.html

Tel : (33) 4 76 41 46 00 (4811)        Fax : (33) 4 76 41 47 47
E-Mail : Axel.Boness@Sema-Grenoble.fr

Re: Code Formatters

[Simon Johnston]

Robert Dewar wrote:
[snip]
> but these are seldome more than very simple issues. I personally don't
> like any editor that messes with me in any way (I hate templates or =
any
> kind of on the fly fixup of what I type), but others really like =
editors
> that help out (e.g. Ada mode in EMACS).

One of my biggest gripes about VisualBasic programming is that damn! =
editor which moves my code around, refuses to allow me to use additional =
spaces to line up code.=20
It does however enforce capitalization, a thorny issue in this group :)

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,----------------------------------------------------------------------=
---.
--|Simon K. Johnston - Technical Architect  (C++/Ada95) |ICL Retail =
Systems |
--|-----------------------------------------------------|St Martins =
Place   |
--|Internet : skj@acm.org                               |51 Bath Road    =
   |
--|Telephone: +44 (0)1753 793600 Fax: +44 (0)1753 793636|Slough          =
   |
--|Internal : 7286 4617   OP Mail: S.K.Johnston@BRA0801 |Berkshire, SL1 =
3UG |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom  =
   |
--`----------------------------------------------------------------------=
---'
end Sig;