Quick question about Ada code formatting.

Quick question about Ada code formatting.

[Peter C. Chapin]

I realize formatting style varies from person to person and from 
organization to organization. Nevertheless some programming language 
communities have definite community standards about how certain language 
constructs should be formatted. For example, it seems universal in this 
community to name variables This_Way.

When it comes to calling subprograms I've seen some sources that put a 
space between the name of the subprogram and the argument list.

   My_Procedure (X, Y, Z);
   A := My_Function (B);

When wrapping such calls the entire argument list is moved down to the 
next line.

   My_Procedure
      (Very_Long, Argument_List, With_Many, Arguments);

In other communities (C/C++) it is more common to leave the space out 
and also to leave the opening '(' on the same line as the procedure 
name.

I'm wondering how universal the above style is among Ada programmers. In 
other words: would it be desirable for me to adopt it as part of my 
personal style guide?

Peter

P.S. Is there an accepted indentation depth among Ada programmers? I've 
seen three spaces in several places and I notice both Ada-mode in Emacs 
and GPS use three spaces by default.

Re: Quick question about Ada code formatting.

[Ludovic Brenta]

"Peter C. Chapin" <pchapin@sover.net> writes:
> I'm wondering how universal the above style is among Ada
> programmers. In other words: would it be desirable for me to adopt
> it as part of my personal style guide?

Yes, this is quite universal, because of the Ada Quality and Style
Guide[1].  Most coding standards I've seen take the AQ&SG as a
starting point and recommend, or even mandate, the same indentation
style.

Another indentation style which I find quite common is:

   Procedure (First_Formal => First_Actual,
              Second_Formal => Second_Actual);

> P.S. Is there an accepted indentation depth among Ada programmers? I've 
> seen three spaces in several places and I notice both Ada-mode in Emacs 
> and GPS use three spaces by default.

Yes.  Three shall be the number of spaces, and the number of spaces
shall be three.  No more, no less.  Two shalt thou not indent, except
that thou then proceedest to three. Four is right out.

This is also from the AQ&SG.

[1] http://www.adaic.org/docs/95style/html/cover.html

-- 
Ludovic Brenta.

Re: Quick question about Ada code formatting.

[Simon Wright]

"Peter C. Chapin" <pchapin@sover.net> writes:

> I realize formatting style varies from person to person and from 
> organization to organization. Nevertheless some programming language 
> communities have definite community standards about how certain language 
> constructs should be formatted. For example, it seems universal in this 
> community to name variables This_Way.
>
> When it comes to calling subprograms I've seen some sources that put a 
> space between the name of the subprogram and the argument list.
>
>    My_Procedure (X, Y, Z);
>    A := My_Function (B);
>
> When wrapping such calls the entire argument list is moved down to the 
> next line.
>
>    My_Procedure
>       (Very_Long, Argument_List, With_Many, Arguments);
>
> In other communities (C/C++) it is more common to leave the space out 
> and also to leave the opening '(' on the same line as the procedure 
> name.
>
> I'm wondering how universal the above style is among Ada programmers. In 
> other words: would it be desirable for me to adopt it as part of my 
> personal style guide?
>
> Peter
>
> P.S. Is there an accepted indentation depth among Ada programmers? I've 
> seen three spaces in several places and I notice both Ada-mode in Emacs 
> and GPS use three spaces by default.

On my current project we decided to use the formatting provided by
GLIDE/GPS and to use the -gnaty switch to check it. You can give a
whole slew of options to -gnaty but it seems far easier to just accept
the defaults even if they aren't what you would be used to. The 3
space indent is a case in point; of course if your editor just does it
for you it's not so hard to accept!

What always baffles me is how people will *not* train themselves to do
what the style checker expects, and will *not* just fix the style
warnings as they go.

Re: Quick question about Ada code formatting.

[Martin Krischik]

Peter C. Chapin wrote:

> When it comes to calling subprograms I've seen some sources that put a
> space between the name of the subprogram and the argument list.
> 
> My_Procedure (X, Y, Z);
> A := My_Function (B);
> 
> When wrapping such calls the entire argument list is moved down to the
> next line.
> 
> My_Procedure
> (Very_Long, Argument_List, With_Many, Arguments);

That's what the GNAT pretty printer does.

> In other communities (C/C++) it is more common to leave the space out
> and also to leave the opening '(' on the same line as the procedure
> name.

I like the space on the same line as well - but the pretty printer will soon
move it down. And basicly I won't fight it.

The GNAT pretty printer uses ASIS to analyse the source and hence makes very
few mistakes and no mistakes that render the code unusable. Yes, I can
layout the code better then the pretty printer but the difference is so
small that I don't see the point in doing manual code layout any more. 

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Simon Wright wrote:

> What always baffles me is how people will *not* train themselves to do
> what the style checker expects, and will *not* just fix the style
> warnings as they go.

A "hand writing" can work for one person, but not for an
other person. People can, and do fight over whose handwriting
viz. Ada style is better. Even neglecting the strong influence
that a font can have on appearance. But I think there are much
more important issues, and just -gnaty is overly strict here.

Good in my (limited) experience:

 - Consistent use of whatever non-typographical convention
   is in use.

 - Comb structure, and then tough may use 4 or 2 spaces or whatever.
   (so does the GNAT default style in constructs that are continued
   on the next line, so...) There is no real harm done when one
   block uses just 2 spaces for the indented lines, and another uses 5.
   I understand that some people go crazy when they find
   knife, spoon, and fork not properly aligned,no matter how good
   or bad the meal is.
   But programming has more to do with recipes and food than with
   the relative angle of eating tools during the "work".
   Also, play with the image of fish & chips in a paper box,
   framed by sterling cutlery

 - Compare how easily something is looked up in the code versus
   how easily something is read (left-right, top-down) in the
   code. These two processes are very different. Their analog
   in regular texts is table versus paragraph. There will have
   to be a compromise, then, unless you think that code that
   looks ordered is code that actually is ordered.

Slightly different handwritings will work. And it makes team mates
feel better, because they can adopt some of their very own hand
writing style nevertheless, without doing harm to others provided
everyone has retained some modicum of flexibility.

An additional proof of -gnaty being overly strict is
when it comes function names in GUI programming.
Many do not want to see '_'s in identifiers when they are
use to them without the underscores. Note the "used to"... :-)

There is a study (from Kent?, comparing MISRA C and other style
guides) that demonstrates how useless and wasteful typographic
sophistry is.

-- Georg

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Georg Bauhaus wrote:

>  - Comb structure, and then tough may use 4 or 2 spaces or whatever.
("thou". Sorry)

Re: Quick question about Ada code formatting.

[Pascal Obry]

Simon Wright a �crit :
> What always baffles me is how people will *not* train themselves to do
> what the style checker expects, and will *not* just fix the style
> warnings as they go.

To enforce it is possible to use a server side checker before the commit
is accepted (Subversion pre-commit hook for example). I'm going this way
for the moment just for this reason ;)

Use the -gnaty (with your style checks setting) plus the -gnats (syntax
only). Some checks can't be do at the syntax level like -gnatyr for
example and -gnats but yet it is a step forward.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Jeffrey R. Carter]

Peter C. Chapin wrote:

>    My_Procedure (X, Y, Z);
>    A := My_Function (B);

This is what I like, if it will fit on one line, except I like named notation 
for procedures.

>    My_Procedure
>       (Very_Long, Argument_List, With_Many, Arguments);

This is what I like if it won't fit on one line with the procedure name, but 
will on a separate line, with the caveat noted above.

If it won't fit on a separate line, then I like

Procedure_Name (First_Param  => First_Param,
                 Second_Param => Second_Param,
                 ...
                 Last_Param   => Last_Param);

> In other communities (C/C++) it is more common to leave the space out 
> and also to leave the opening '(' on the same line as the procedure 
> name.

There's little from the C/++ world worth adopting.

> P.S. Is there an accepted indentation depth among Ada programmers? I've 
> seen three spaces in several places and I notice both Ada-mode in Emacs 
> and GPS use three spaces by default.

2-4 is an acceptable range, and 3 is in the middle of that. I personally use 3.

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Quick question about Ada code formatting.

[Peter C. Chapin]

Simon Wright <simon@pushface.org> wrote in
news:m2vevcpzlq.fsf@grendel.local: 

> On my current project we decided to use the formatting provided by
> GLIDE/GPS and to use the -gnaty switch to check it. You can give a
> whole slew of options to -gnaty but it seems far easier to just accept
> the defaults even if they aren't what you would be used to.

Thanks for your comments and to all the others who have responded. Thanks 
also for drawing my attention to -gnaty. That seems handy. I'm sure there 
must be other style checkers out there too.

Peter

Re: Quick question about Ada code formatting.

[Pascal Obry]

Peter C. Chapin a �crit :

> Thanks for your comments and to all the others who have responded. Thanks 
> also for drawing my attention to -gnaty. That seems handy. I'm sure there 
> must be other style checkers out there too.

Yes AdaControl from J.P. Rosen and gnatcheck from AdaCore. But -gnaty
(when using GNAT) is the enforcement at the compilation level before
anything is checked-in. I always use it with -gnatw (warnings) and most
importantly with -gnatwe (warnings are error) so GNAT will refuse to
compile code. A nice way to force people to use the right style ;) Of
course I have seen some developers editing the project file to remove
options like -gnaty, -gnatwe :( ... that's why I'm going to enforce the
rules at the repository level where I have full control.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Yes AdaControl from J.P. Rosen and gnatcheck from AdaCore. But -gnaty
> (when using GNAT) is the enforcement at the compilation level before
> anything is checked-in. I always use it with -gnatw (warnings) and most
> importantly with -gnatwe (warnings are error) so GNAT will refuse to
> compile code. A nice way to force people to use the right style ;) Of
> course I have seen some developers editing the project file to remove
> options like -gnaty, -gnatwe :( ... that's why I'm going to enforce the
> rules at the repository level where I have full control.

Of course you will always find the bozo who discovers

   pragma Style_Checks (Off);

and puts it at the start of his source file. I was spitting tacks when
I discovered that .. 

Re: Quick question about Ada code formatting.

[Simon Wright]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> A "hand writing" can work for one person, but not for an
> other person. People can, and do fight over whose handwriting
> viz. Ada style is better. Even neglecting the strong influence
> that a font can have on appearance. But I think there are much
> more important issues, and just -gnaty is overly strict here.

I don't believe that what we are doing is art. Artists tend not to get
paid as much as that.

If people won't abide by the simple things like the project style
guide, it acts as a warning bell that they're probably ignoring other,
more important, things.

> Good in my (limited) experience:
>
>  - Consistent use of whatever non-typographical convention
>    is in use.

Yes, precisely. That is *exactly* the point!

> An additional proof of -gnaty being overly strict is when it comes
> function names in GUI programming.  Many do not want to see '_'s in
> identifiers when they are use to them without the underscores. Note
> the "used to"... :-)

I don't understand that. I have GLIDE and GPS set up to recognise the
correct casing of lots of words: my ~/.emacs_case_exceptions is

ASCL
AUnit
BC
ColdFrame
GNAT
IDE
PragmaRC
*AVL
*DOM
*EWS
*HTTP
*IO
*XML

so that, for example, Text_IO comes out exactly like that as I
type. And ColdFrame like that.

> There is a study (from Kent?, comparing MISRA C and other style
> guides) that demonstrates how useless and wasteful typographic
> sophistry is.

Hmm, can't find anything like that on Google, any more pointers?

Re: Quick question about Ada code formatting.

[Jeffrey R. Carter]

Simon Wright wrote:
> I don't understand that. I have GLIDE and GPS set up to recognise the
> correct casing of lots of words: my ~/.emacs_case_exceptions is
> 
> ...
> PragmaRC

This, a contraction of PragmAda Reusable Components, is cased PragmARC in the 
source files.

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Quick question about Ada code formatting.

[Pascal Obry]

Simon Wright a �crit :

> and puts it at the start of his source file. I was spitting tacks when
> I discovered that .. 

Just add a check on the server side that there is no Style_Check() off.
This is trivial, I have already a simple Ada program to check that there
is no space at the end of line, that there is no duplicate blank lines
and so on... Adding a test for no pragma Style_Check off would be trivial...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Simon Wright]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Simon Wright wrote:
>> I don't understand that. I have GLIDE and GPS set up to recognise the
>> correct casing of lots of words: my ~/.emacs_case_exceptions is
>> ...
>> PragmaRC
>
> This, a contraction of PragmAda Reusable Components, is cased PragmARC
> in the source files.

Oops, corrected -- thanks

Re: Quick question about Ada code formatting.

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> Just add a check on the server side that there is no Style_Check()
> off.  This is trivial, I have already a simple Ada program to check
> that there is no space at the end of line, that there is no
> duplicate blank lines and so on... Adding a test for no pragma
> Style_Check off would be trivial...

Sometimes we end up with the (equivalent of) $RCSfile$ being too long
.. so it's always good to allow exceptions .. so long as there's (say)
a pragma Style_Check (On) within a few lines of the (Off)? .. all
getting rather complex, but of course do-able.

What do you have against double blank lines? Triple blank lines, now
that would be eeeevil.

Re: Quick question about Ada code formatting.

[Dmitry A. Kazakov]

On 18 Feb 2006 12:19:59 GMT, Peter C. Chapin wrote:

> I realize formatting style varies from person to person and from 
> organization to organization. Nevertheless some programming language 
> communities have definite community standards about how certain language 
> constructs should be formatted. For example, it seems universal in this 
> community to name variables This_Way.
> 
> When it comes to calling subprograms I've seen some sources that put a 
> space between the name of the subprogram and the argument list.
> 
>    My_Procedure (X, Y, Z);
>    A := My_Function (B);
> 
> When wrapping such calls the entire argument list is moved down to the 
> next line.
> 
>    My_Procedure
>       (Very_Long, Argument_List, With_Many, Arguments);
> 
> In other communities (C/C++) it is more common to leave the space out 
> and also to leave the opening '(' on the same line as the procedure 
> name.
> 
> I'm wondering how universal the above style is among Ada programmers. In 
> other words: would it be desirable for me to adopt it as part of my 
> personal style guide?

I do it this way.

My_Procedure
(  A => X, -- Place for a comment
   B => Y,
   C => Z
);

Opening and closing brackets have same indentation.

 > P.S. Is there an accepted indentation depth among Ada programmers?

I use 3, because it conforms with name length of the most of operations, 
which I always put first on each new line. For example, a long formula (to 
be avoided if possible):

X :=
   (  (  Y
      +  Z
      +  ...
      )
   /  100
   );

Though it does not well fit for "and", "and then", "or else". Anyway if 
My_Function need called there, it becomes:

X :=
   (  (  Y
      +  My_Function
         (  Arg1 => Something,
            Arg2 => 34 / Z,
            ...
            ArgN => K -- It's a bad idea to have long argument lists
      )  )
   /  100
   );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Quick question about Ada code formatting.

[Pascal Obry]

Simon Wright a �crit :

> What do you have against double blank lines? Triple blank lines, now
> that would be eeeevil.

They convey no information.

That's just a style and feeling may differ ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Simon Wright wrote:

>>  - Consistent use of whatever non-typographical convention
>>    is in use.
> 
> Yes, precisely. That is *exactly* the point!

But indentation using 2 or 4 or 3 spaces is a typographical
issue. -gnaty without further qualification is rather unforgiving
when it forces reformatting of reused source code that happens not
to follow -gnaty's defaults. The same comment applies to space
before '(' and after "-- ". I'd prefer a less intrusive default
meaning of -gnaty.

-gnaty could be improved, in my view, by separating layout
issues from issues that potentially affect how a piece of
code can be organized, and compiled.

For example, on the one hand -gnaty marks
test.ada:2:04: (style) subprogram body has no previous spec

and on the other hand,
test.ada:3:09: (style) space required

These messages point to different issues, the first says something
about a program's organization. It refers to the fundamental
issue of separating spec and implementation. The second is largely
a typographic issue. It has no relevance for program organization.


>> An additional proof of -gnaty being overly strict is when it comes
>> function names in GUI programming.  Many do not want to see '_'s in
>> identifiers when they are use to them without the underscores. Note
>> the "used to"... :-)
> 
> I don't understand that. I have GLIDE and GPS set up to recognise the
> correct casing of lots of words: my ~/.emacs_case_exceptions is

I was confused. There are style rules that say that Ada style identifiers
with '_' are always prefereble, so please rewrite the system call names.
CreateWindow then becomes Create_Window, and not Windows.Create, say.
The latter leaves no doubt that there is a layer of abstraction.

(Side note: The SmartEiffel team has decided to modify their Eiffel
language such that typical Eiffel style rules become syntax rules.
No exceptions.
This entails case restrictions, referred to as "case sensitivity".
So no more "Henry_III" constant identifiers in SmartEiffel programs,
only "Henry_iii". One version of the compiler in fact forced you
to write "henry_iii". And SmartEiffel, the official name, is written
"smart_eiffel" in the source files.)

>> There is a study (from Kent?, comparing MISRA C and other style
>> guides) that demonstrates how useless and wasteful typographic
>> sophistry is.
> 
> Hmm, can't find anything like that on Google, any more pointers?

The latest version I could find is here,
http://www.leshatton.org/Documents/MISRAC.pdf

The wording seems to have softened since a version dated 2002/05/24.
The paragraph below Table 2 in that version starts:

"The clear message from these studies is that a category A dominated
programming standard is a complete waste of everybody's time and money."

(Category A means "inherently artistic", "subjectively or stylistically
based" rules. Category B.1 has "folklore rules" (e.g., no goto, never!)
and B.2 denotes rules for which there exist actual data from measuring
failures when not following these rules.)

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Pascal Obry wrote:
> Simon Wright a �crit :
> 
>> What do you have against double blank lines? Triple blank lines, now
>> that would be eeeevil.
> 
> They convey no information.

They can indicate a major block. For example in Matt's AI 302
implementation, there are blank lines between many executable
statements. There are two blank lines between most, if not all,
subprograms.

Re: Quick question about Ada code formatting.

[Pascal Obry]

Georg Bauhaus a �crit :

> They can indicate a major block. For example in Matt's AI 302
> implementation, there are blank lines between many executable
> statements. There are two blank lines between most, if not all,
> subprograms.

Between subprograms I prefer the "GNAT style" header box:

  ----------------------
  -- Process_Whatever --
  ----------------------

  procedure Process_Whatever is
  ...

Far clearer than 2 blank lines IMHO.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Stephen Leake]

Pascal Obry <pascal@obry.net> writes:

> Yes AdaControl from J.P. Rosen and gnatcheck from AdaCore. But -gnaty
> (when using GNAT) is the enforcement at the compilation level before
> anything is checked-in. I always use it with -gnatw (warnings) and most
> importantly with -gnatwe (warnings are error) so GNAT will refuse to
> compile code. A nice way to force people to use the right style ;) 

It helps to combine that with an intelligent editor that can
automatically fix the style errors reported. AdaCore's GPS can do some
of that, as can Emacs Ada mode.

> Of course I have seen some developers editing the project file to
> remove options like -gnaty, -gnatwe :( ... that's why I'm going to
> enforce the rules at the repository level where I have full control.

I guess firing the people who violate the rules isn't an option?

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Pascal Obry <pascal@obry.net> writes:

> Georg Bauhaus a �crit :
>
>> They can indicate a major block. For example in Matt's AI 302
>> implementation, there are blank lines between many executable
>> statements. There are two blank lines between most, if not all,
>> subprograms.
>
> Between subprograms I prefer the "GNAT style" header box:
>
>   ----------------------
>   -- Process_Whatever --
>   ----------------------
>
>   procedure Process_Whatever is
>   ...
>
> Far clearer than 2 blank lines IMHO.

Yuck - a waste of valuable screen space. That's what syntax
colorization is for, along with navigation keys (page forward goes to
next subprogram).

One of these days, I'll add an option to gnatstub to take those out.

Just my style, of course :).

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> "Jeffrey R. Carter" <spam@spam.com> writes:
>
>> Simon Wright wrote:
>>> I don't understand that. I have GLIDE and GPS set up to recognise the
>>> correct casing of lots of words: my ~/.emacs_case_exceptions is
>>> ...
>>> PragmaRC
>>
>> This, a contraction of PragmAda Reusable Components, is cased PragmARC
>> in the source files.
>
> Oops, corrected -- thanks

Hmm. With the proper GNAT style settings, the compiler should have
caught that for you; -gnatyr checks that uses of identifiers have the
same casing as the declaration.

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Jeffrey R. Carter]

Pascal Obry wrote:

> Between subprograms I prefer the "GNAT style" header box:
> 
>   ----------------------
>   -- Process_Whatever --
>   ----------------------
> 
>   procedure Process_Whatever is

Comments should add value; these blocks add nothing. You can tell it's 
Process_Whatever from the next non-comment, non-blank line. This is about as 
useful as

-- Add 1 to X
X := X + 1;

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: Quick question about Ada code formatting.

[Pascal Obry]

Jeffrey R. Carter a �crit :
> Pascal Obry wrote:
> 
>> Between subprograms I prefer the "GNAT style" header box:
>>
>>   ----------------------
>>   -- Process_Whatever --
>>   ----------------------
>>
>>   procedure Process_Whatever is
> 
> Comments should add value; these blocks add nothing. You can tell it's
> Process_Whatever from the next non-comment, non-blank line. This is
> about as useful as
> 
> -- Add 1 to X
> X := X + 1;

I just do not agree, it helps a lot browsing and looking for a specific
routine in a source file. It is not a really comment certainly not
something you can compare with "Add 1 to X" ! It is a kind of separator
that clearly stand out. BTW, this is the GNAT style, a style that I use
for AWS... But again this is just one style.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Simon Wright]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> But indentation using 2 or 4 or 3 spaces is a typographical
> issue. -gnaty without further qualification is rather unforgiving
> when it forces reformatting of reused source code that happens not
> to follow -gnaty's defaults. The same comment applies to space
> before '(' and after "-- ". I'd prefer a less intrusive default
> meaning of -gnaty.

=gnaty was introduced to support AdaCore's in-house rules. I see no
point in writing a massively complex stylistic guide, we need a tool
(preferably an already-available one), so we just adopted -gnaty for
new code. As I've said before, I have little time for the artistic
approach if it leads to so-called engineers refusing to do what
they're paid to.

On the other hand, for re-used code (eg a matrix package, and even at
one point AUnit) we switched off -gnaty; we had no intention of
altering it, and indeed we had reasonably strict rules not to do so
without showing that it was truly necessary (style _not_ coming under
that heading!)

> -gnaty could be improved, in my view, by separating layout
> issues from issues that potentially affect how a piece of
> code can be organized, and compiled.
>
> For example, on the one hand -gnaty marks
> test.ada:2:04: (style) subprogram body has no previous spec
>
> and on the other hand,
> test.ada:3:09: (style) space required

The first case you mention seems to be the only -gnaty rule that has
any semantic effect at all, all the others are indeed style.

We also compile with -gnatwaL which is reasonably strict. I think
there are a coule of warnings not switched on by -gnatwa -- yes, d
(implicit dereferencing) and h (hiding) for a start.


>>> There is a study (from Kent?, comparing MISRA C and other style
>>> guides) that demonstrates how useless and wasteful typographic
>>> sophistry is.
>> 
>> Hmm, can't find anything like that on Google, any more pointers?
>
> The latest version I could find is here,
> http://www.leshatton.org/Documents/MISRAC.pdf
>
> The wording seems to have softened since a version dated 2002/05/24.
> The paragraph below Table 2 in that version starts:
>
> "The clear message from these studies is that a category A dominated
> programming standard is a complete waste of everybody's time and money."
>
> (Category A means "inherently artistic", "subjectively or stylistically
> based" rules. Category B.1 has "folklore rules" (e.g., no goto, never!)
> and B.2 denotes rules for which there exist actual data from measuring
> failures when not following these rules.)

I found the paper quite confused. It says that -- without tool support
-- a standard for C gets transgressed about once every 10 lines,
regardless of whether it's mainly A-based (stylistic) or B-based
(semantic).

Clearly one needs compiler halp as much as possible. If it has a
switch to warn about possibly-uninitialised variables one would be
irresponsible not to use it. Ditto for style, surely?

I also saw no evidence in it about whether code that didn't transgress
stylistic rules had fewer semantic errors as well.


I remember the Rational Environment. You had no choice about how your
code was presented, because the internal representation didn't store
layout; all you saw after the code had been internalised (semanticised
was the word they used) was a view of it, prepared on the fly. One
pretty soon got out of the habit of trying to force the system to do
something else!

Re: Quick question about Ada code formatting.

[Simon Wright]

Pascal Obry <pascal@obry.net> writes:

> I just do not agree, it helps a lot browsing and looking for a
> specific routine in a source file. It is not a really comment
> certainly not something you can compare with "Add 1 to X" ! It is a
> kind of separator that clearly stand out. BTW, this is the GNAT
> style, a style that I use for AWS... But again this is just one
> style.

Both GLIDE and GPS make it easy to find things in source files --
types, subprograms, tasks, protected types, packages ...

Re: Quick question about Ada code formatting.

[Simon Wright]

Stephen Leake <stephe_on_the_web@toadmail.com> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> "Jeffrey R. Carter" <spam@spam.com> writes:
>>
>>> Simon Wright wrote:
>>>> I don't understand that. I have GLIDE and GPS set up to recognise the
>>>> correct casing of lots of words: my ~/.emacs_case_exceptions is
>>>> ...
>>>> PragmaRC
>>>
>>> This, a contraction of PragmAda Reusable Components, is cased PragmARC
>>> in the source files.
>>
>> Oops, corrected -- thanks
>
> Hmm. With the proper GNAT style settings, the compiler should have
> caught that for you; -gnatyr checks that uses of identifiers have the
> same casing as the declaration.

Indeed. I must say I don't remember exactly why Pragm[aA]RC got in
there, you won't be surprised that I still use the BCs for most
things.

Re: Quick question about Ada code formatting.

[Jeffrey R. Carter]

Pascal Obry wrote:
> I just do not agree, it helps a lot browsing and looking for a specific
> routine in a source file. It is not a really comment certainly not
> something you can compare with "Add 1 to X" ! It is a kind of separator
> that clearly stand out. BTW, this is the GNAT style, a style that I use
> for AWS... But again this is just one style.

I seem to have no difficulty finding subprograms in source code without block 
comments that duplicate the code. "procedure" and "function" at the proper 
indentation levels are quite easy to detect. Add an editor that colors reserved 
words and such comment blocks seem less than useless.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: Quick question about Ada code formatting.

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephe_on_the_web@toadmail.com> writes:

    >> ----------------------
    >> -- Process_Whatever --
    >> ----------------------
    >> 
    >> procedure Process_Whatever is
    >> ...
    >> 
    >> Far clearer than 2 blank lines IMHO.

    Stephen> Yuck - a waste of valuable screen space. That's what
    Stephen> syntax colorization is for, along with navigation keys
    Stephen> (page forward goes to next subprogram).

If you have long functions (yes, this might be pure evil in itself),
then comments like the above help separate the different functions
(even with good colour scheme this isn't always easy, especially if
you have a lot of nested levels or even nested functions).

However, the above is just asking for the comment to be expanded to
clearly describe what on earth "Process_Whatever" does, and why it is
different from the following procedures "Process_Whatever_2",
"Princess_Whatever3", or "process_what_Ever_4".

    Stephen> Just my style, of course :).

Just my experience.

(yes; I do see some crazy names used in actual code, both open source
and closed source, that leave you thinking you know what a
subroutine/function does when you really don't)
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Quick question about Ada code formatting.

[Jean-Pierre Rosen]

Simon Wright a �crit :
> Of course you will always find the bozo who discovers
> 
>    pragma Style_Checks (Off);
> 
> and puts it at the start of his source file. I was spitting tacks when
> I discovered that .. 
<shameless plug>
Of course you should have used AdaControl with the rule:
    check pragmas (style_check);
</shameless plug>

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Quick question about Ada code formatting.

[Lionel Draghi]

Stephen Leake a ï¿œcrit :

> Pascal Obry <pascal@obry.net> writes:
>>Between subprograms I prefer the "GNAT style" header box:
>>
>>  ----------------------
>>  -- Process_Whatever --
>>  ----------------------
>>
>>  procedure Process_Whatever is
>>  ...
>>
>>Far clearer than 2 blank lines IMHO.
> 
> 
> Yuck - a waste of valuable screen space. That's what syntax
> colorization is for, along with navigation keys (page forward goes to
> next subprogram).

I agree.
Sam's point about this style (some weeks ago in cla) was to put an 
emphasis on procedure start to ease reading the code in simple text 
editor. I don't think that vi or such are still used enough to justify 
such a "waste of valuable screen space".

I think most people are using emacs/gps/etc., have no problem in code 
navigation.

Anyway, there are several way to put emphasis on operations without 
wasting screen space, and without duplicating the procedure name in the 
comment, for example:

procedure Process_Whatever is
-- ----------------------------------------------------------

or

-- ----------------------------------------------------------
procedure Process_Whatever is

etc.

And no, this is not "my taste", but an arguable scientific point
:-)

-- 
Lionel Draghi

Re: Quick question about Ada code formatting.

[Pascal Obry]

Brian May a �crit :

> However, the above is just asking for the comment to be expanded to
> clearly describe what on earth "Process_Whatever" does, and why it is
> different from the following procedures "Process_Whatever_2",
> "Princess_Whatever3", or "process_what_Ever_4".

I'm using a style where the spec must be declared. So the doc goes with
the spec (not with the body).

   procedure Process_Whatever;
   --  Do the right thing bla bla bla

On the body I comment about the implementation. This is also a good way
to separate the usage documentation on the spec and the technical one on
the body.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Pascal Obry]

Stephen Leake a �crit :

> Yuck - a waste of valuable screen space. That's what syntax
> colorization is for, along with navigation keys (page forward goes to
> next subprogram).

Well between routines the space is... empty ! It wont be good to have
this inside a body where you need to have an open view on the structures
of the loop, if... and so on. But between routine I don't see the header
being so annoying. Again this is just style ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Martin Krischik]

Lionel Draghi wrote:

> I don't think that vi or such are still used enough to justify
> such a "waste of valuable screen space".

Todays vi's all have color code as well.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Quick question about Ada code formatting.

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message
news:43F872C4.50505@obry.net...
> Georg Bauhaus a �crit :
>
> > They can indicate a major block. For example in Matt's AI 302
> > implementation, there are blank lines between many executable
> > statements. There are two blank lines between most, if not all,
> > subprograms.
>
> Between subprograms I prefer the "GNAT style" header box:
>
>   ----------------------
>   -- Process_Whatever --
>   ----------------------
>
>   procedure Process_Whatever is
>   ...
>
> Far clearer than 2 blank lines IMHO.

But extremely hard to maintain. We used a style like that in the Janus/Ada
compiler, and we found that we were spending a lot of time lining up the
closing hyphens ever time the comment changed in some way. We abandoned the
whole idea with Claw, and went to two blank lines between subprograms.

After all, the idea isn't to carry any information, but to simply to
separate the procedures. (Comments that repeat what is obviously known by
reading the source code are evil, IMHO, so I find this comment wasteful.)
Perhaps a better approach would be to include a dashed line separator
between procedures -- but that takes *three* lines, and since you never have
enough screen real estate, so it seems like a waste.

                        Randy.

Re: Quick question about Ada code formatting.

[Alex R. Mosteo]

Pascal Obry wrote:
> Stephen Leake a �crit :
> 
> 
>>Yuck - a waste of valuable screen space. That's what syntax
>>colorization is for, along with navigation keys (page forward goes to
>>next subprogram).
> 
> 
> Well between routines the space is... empty ! It wont be good to have
> this inside a body where you need to have an open view on the structures
> of the loop, if... and so on. But between routine I don't see the header
> being so annoying. Again this is just style ;)

Yep, it seems we are in the minority here... but I too like to see a 
good bunch of blue between subprograms.

Re: Quick question about Ada code formatting.

[Simon Wright]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Simon Wright a �crit :
>> Of course you will always find the bozo who discovers
>>    pragma Style_Checks (Off);
>> and puts it at the start of his source file. I was spitting tacks
>> when
>> I discovered that .. 
> <shameless plug>
> Of course you should have used AdaControl with the rule:
>     check pragmas (style_check);
> </shameless plug>

As indeed I remarked to Pascal via mail ...

Re: Quick question about Ada code formatting.

[Stephen Leake]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> -gnaty could be improved, in my view, by separating layout
> issues from issues that potentially affect how a piece of
> code can be organized, and compiled.
>
> For example, on the one hand -gnaty marks
> test.ada:2:04: (style) subprogram body has no previous spec
>
> and on the other hand,
> test.ada:3:09: (style) space required
>
> These messages point to different issues, the first says something
> about a program's organization. It refers to the fundamental
> issue of separating spec and implementation. The second is largely
> a typographic issue. It has no relevance for program organization.

These are separate warnings; one is -gnatys, the other -gnatyt.

I guess you would rather have -gnatzs, and -gnatyt? I don't see the
point.

The fact that the GNAT compiler groups them under -gnaty isn't
particularly relevant, unless you happen to like the defaults.

I always assume the defaults for any particular compiler switch are
probably not what I want.

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

>>>>>> "Stephen" == Stephen Leake <stephe_on_the_web@toadmail.com> writes:
>
>     >> ----------------------
>     >> -- Process_Whatever --
>     >> ----------------------
>     >> 
>     >> procedure Process_Whatever is
>     >> ...
>     >> 
>     >> Far clearer than 2 blank lines IMHO.
>
>     Stephen> Yuck - a waste of valuable screen space. That's what
>     Stephen> syntax colorization is for, along with navigation keys
>     Stephen> (page forward goes to next subprogram).
>
> If you have long functions (yes, this might be pure evil in itself),
> then comments like the above help separate the different functions
> (even with good colour scheme this isn't always easy, especially if
> you have a lot of nested levels or even nested functions).

Nonsense. The indentation says whether a particular function
declaration is top-level or not. As others have pointed out, finding
the top level function declaration is what IDE navigation is for; in
my Emacs, 'M-page up' goes to the previous top-level function
declaration. Having the block comment there adds no information.

Please show an actual example where the comment adds information that
is _not_ present in the indentation or keyword (presumed colorized).

> However, the above is just asking for the comment to be expanded to
> clearly describe what on earth "Process_Whatever" does, and why it is
> different from the following procedures "Process_Whatever_2",
> "Princess_Whatever3", or "process_what_Ever_4".

No, that information belongs in the spec of the package.

Well, it could be that Process_Whatever is local to the package body,
and this _is_ the spec. Then there should be a comment describing it.

> (yes; I do see some crazy names used in actual code, both open source
> and closed source, that leave you thinking you know what a
> subroutine/function does when you really don't)

That's what code reviews are for :).

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

> I don't think that vi or such are still used enough to justify
> such a "waste of valuable screen space".

I would never presume to make that statement. I have no way of
surveying "the community at large" to find out what IDE's/editors are
being used.

> I think most people are using emacs/gps/etc., have no problem in code
> navigation.

On _my_ projects, developers are required to use tools that
significantly improve productivity. But on other projects, I still run
into people using vi. Just last month, one guy had the compiler on one
machine, and an editor on another, and used scp to copy between them.
Absolutely amazing! So I showed him how to use X windows to run
Eclipse on the same machine as the compiler (yes, I recommend Eclipse
to newbies now, over Emacs; it does seem like a better base). I should
have demanded 10% of his next raise, assuming he gets a raise based on
productivity :).

> Anyway, there are several way to put emphasis on operations without
> wasting screen space, and without duplicating the procedure name in
> the comment, for example:
>
> procedure Process_Whatever is
> -- ----------------------------------------------------------
>
> or
>
> -- ----------------------------------------------------------
> procedure Process_Whatever is
>
> etc.
>
> And no, this is not "my taste", but an arguable scientific point
> :-)

Hmm. I'm still missing something. You have a line full of hyphens.
I think that wastes screen space.

What information do those hyphens add over the indentation and the
keyword 'procedure'?

To ask it another way: are there procedures (or functions) that are
_not_ marked in this way? If so, that would be additional information
(although I don't know what that information is). If not, it's just
noise. 

Unless that smiley means it _is_ still just personal taste.

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Pascal Obry wrote:
>> Stephen Leake a �crit :
>>
>>>Yuck - a waste of valuable screen space. That's what syntax
>>>colorization is for, along with navigation keys (page forward goes to
>>>next subprogram).
>> Well between routines the space is... empty ! It wont be good to have
>> this inside a body where you need to have an open view on the structures
>> of the loop, if... and so on. But between routine I don't see the header
>> being so annoying. Again this is just style ;)
>
> Yep, it seems we are in the minority here... but I too like to see a
> good bunch of blue between subprograms.

"Blue"? Surely you mean "pale goldenrod"!

Flame on :).

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Pascal Obry" <pascal@obry.net> wrote in message
> news:43F872C4.50505@obry.net...
>> Georg Bauhaus a �crit :
>>
>> > They can indicate a major block. For example in Matt's AI 302
>> > implementation, there are blank lines between many executable
>> > statements. There are two blank lines between most, if not all,
>> > subprograms.
>>
>> Between subprograms I prefer the "GNAT style" header box:
>>
>>   ----------------------
>>   -- Process_Whatever --
>>   ----------------------
>>
>>   procedure Process_Whatever is
>>   ...
>>
>> Far clearer than 2 blank lines IMHO.
>
> But extremely hard to maintain. We used a style like that in the Janus/Ada
> compiler, and we found that we were spending a lot of time lining up the
> closing hyphens ever time the comment changed in some way. 

Yes. One of the projects I'm on (GWindows) also requires this style.
After the first couple of days, I wrote an Emacs macro to write the
comment for me.

Customizable tools are essential.

Just out of curiosity; has any GPS user out there written a macro like
that for GPS? In general, how easy is it to write macros for GPS?

> After all, the idea isn't to carry any information, but to simply to
> separate the procedures. (Comments that repeat what is obviously known by
> reading the source code are evil, IMHO, so I find this comment wasteful.)
> Perhaps a better approach would be to include a dashed line separator
> between procedures -- but that takes *three* lines, and since you never have
> enough screen real estate, so it seems like a waste.

Right on :). 

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Pascal Obry]

Stephen,

> What information do those hyphens add over the indentation and the
> keyword 'procedure'?

No information. Just that on the screen I can see more easily where the
routines start. That's all but quite useful to me no matter the IDE I'm
using (Emacs or GPS most of the time).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Stephen Leake wrote:

> These are separate warnings; one is -gnatys, the other -gnatyt.

The warnings aren't separate in the sense that GNAT
characterizes both as "(style)", but one style is writing
a spec or not, the other style refers to typography,
i.e. content versus form.

> I guess you would rather have -gnatzs, and -gnatyt? I don't see the
> point.

I'd rather have -gnatY and -gnaty where the first is for checking
Ada language style, and the other for checking layout etc..

A possible thing for -gnatY to achieve could be something like
the following (don't know if this easily added to GNAT, or in
fact already present):

blue.ads: 5: (Y-style) use clause for Ada.Text_IO is not needed


with Ada.Text_IO;

package Blue is

   use Ada.Text_IO;

   subtype File_Type is Ada.Text_IO.File_Type;

end Blue;

Re: Quick question about Ada code formatting.

[Jeffrey R. Carter]

Stephen Leake wrote:

> "Blue"? Surely you mean "pale goldenrod"!

You heathen! Comments should be chartreuse! :)

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: Quick question about Ada code formatting.

[Alex R. Mosteo]

Stephen Leake wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> 
>>"Pascal Obry" <pascal@obry.net> wrote in message
>>news:43F872C4.50505@obry.net...
>>
>>>Georg Bauhaus a �crit :
>>>
>>>
>>>>They can indicate a major block. For example in Matt's AI 302
>>>>implementation, there are blank lines between many executable
>>>>statements. There are two blank lines between most, if not all,
>>>>subprograms.
>>>
>>>Between subprograms I prefer the "GNAT style" header box:
>>>
>>>  ----------------------
>>>  -- Process_Whatever --
>>>  ----------------------
>>>
>>>  procedure Process_Whatever is
>>>  ...
>>>
>>>Far clearer than 2 blank lines IMHO.
>>
>>But extremely hard to maintain. We used a style like that in the Janus/Ada
>>compiler, and we found that we were spending a lot of time lining up the
>>closing hyphens ever time the comment changed in some way. 
> 
> 
> Yes. One of the projects I'm on (GWindows) also requires this style.
> After the first couple of days, I wrote an Emacs macro to write the
> comment for me.
> 
> Customizable tools are essential.
> 
> Just out of curiosity; has any GPS user out there written a macro like
> that for GPS? In general, how easy is it to write macros for GPS?

GPS already has a macro for this, you simply have to give a key binding 
to it. I personally use Ctrl+B and voil�, subprogram box with null effort.

Otherwise I agree that it would be quite painful.

>>After all, the idea isn't to carry any information, but to simply to
>>separate the procedures. (Comments that repeat what is obviously known by
>>reading the source code are evil, IMHO, so I find this comment wasteful.)
>>Perhaps a better approach would be to include a dashed line separator
>>between procedures -- but that takes *three* lines, and since you never have
>>enough screen real estate, so it seems like a waste.
> 
> 
> Right on :). 
> 

Re: Quick question about Ada code formatting.

[Jean-Pierre Rosen]

Stephen Leake a �crit :
> Yes. One of the projects I'm on (GWindows) also requires this style.
> After the first couple of days, I wrote an Emacs macro to write the
> comment for me.
> 
Would you care to make that macro available?
I certainly would like it, and I guess I would not be the only one....

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Quick question about Ada code formatting.

[Stephen Leake]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> Stephen Leake wrote:
>
>> These are separate warnings; one is -gnatys, the other -gnatyt.
>
> The warnings aren't separate in the sense that GNAT
> characterizes both as "(style)", but one style is writing
> a spec or not, the other style refers to typography,
> i.e. content versus form.
>
>> I guess you would rather have -gnatzs, and -gnatyt? I don't see the
>> point.
>
> I'd rather have -gnatY and -gnaty where the first is for checking
> Ada language style, and the other for checking layout etc..

Well, that violates the GNAT option capitalization convention;
uppercase turns options off, lowercase turns them on.

> A possible thing for -gnatY to achieve could be something like
> the following (don't know if this easily added to GNAT, or in
> fact already present):
>
> blue.ads: 5: (Y-style) use clause for Ada.Text_IO is not needed
>
>
> with Ada.Text_IO;
>
> package Blue is
>
>    use Ada.Text_IO;
>
>    subtype File_Type is Ada.Text_IO.File_Type;
>
> end Blue;

Reporting some unnecessary use clauses is in GNAT 5.04, but it doesn't
report this case. I agree it would be nice. 

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Pascal Obry <pascal@obry.net> writes:

> Stephen,
>
>> What information do those hyphens add over the indentation and the
>> keyword 'procedure'?
>
> No information. Just that on the screen I can see more easily where the
> routines start. 

"more easily" implies _some_ information content. But I guess it's
purely visual, not semantic.

> That's all but quite useful to me no matter the IDE I'm using (Emacs
> or GPS most of the time).

If the IDE displayed the keyword 'procedure' (or that whole line) in a
much larger font, would that be easy enough to see?

I'm looking for a way for the IDE to add the necessary visual cues,
without cluttering the actual code with unnecessary, hard to maintain
comments. For me and others, colorization and navigation is enough;
for you and others, more seems to be needed. That makes this a
personal IDE customization issue, rather than a coding style issue.

On the other hand, if you want a visual clue that is independent of
the IDE, then comments is the right choice.

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Stephen Leake wrote:
>
>> "Blue"? Surely you mean "pale goldenrod"!
>
> You heathen! Comments should be chartreuse! :)

It's not the comment color; it's the background color (review the
context :). I'm guessing you use dark salmon for the background?

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Martin Krischik]

> If the IDE displayed the keyword 'procedure' (or that whole line) in a
> much larger font, would that be easy enough to see?

Cool idea, I imedialtly opened my vim configuration and closed it just
as fast again.

Problem:

procedure xxx (
  aaaa : bbbb := mmmm;
  ccccc: dddd ) renames yyyy;

I tried before for syntax folding and failed - Ada's syntax is just to
flexible.

So you would need a very Ada centric IDE like the GPS to implement that
feature.

Martin

Re: Quick question about Ada code formatting.

[Jean-Pierre Rosen]

Stephen Leake a �crit :
>> with Ada.Text_IO;
>>
>> package Blue is
>>
>>    use Ada.Text_IO;
>>
>>    subtype File_Type is Ada.Text_IO.File_Type;
>>
>> end Blue;
> 
> Reporting some unnecessary use clauses is in GNAT 5.04, but it doesn't
> report this case. I agree it would be nice. 
> 

This is not obvious. In AdaControl, we do not report it either, purposedly.

If you use "use" to document where a package is actually used, it is 
useful to keep it even if it happens that full notation is used.

Remember that reporting unnecessary use clauses is useful to those who 
want to use the use clause! For others... well, there is another rule in 
AdaControl to check all use clauses.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Quick question about Ada code formatting.

[Stephen Leake]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

>> If the IDE displayed the keyword 'procedure' (or that whole line) in a
>> much larger font, would that be easy enough to see?
>
> Cool idea, I imedialtly opened my vim configuration and closed it just
> as fast again.
>
> Problem:
>
> procedure xxx (
>   aaaa : bbbb := mmmm;
>   ccccc: dddd ) renames yyyy;
>
> I tried before for syntax folding and failed - Ada's syntax is just to
> flexible.
>
> So you would need a very Ada centric IDE like the GPS to implement that
> feature.

Hmph. Emacs can do this easily. Well, it can easily set the font to
large for _all_ keywords (I just did that, via interactive
customization). It would not be hard to just set the font to large for
a subset of keywords.

For those who want to experiment with this; start customize, navigate
to Faces | Font Lock | Font Lock Highlighting Faces | Font Lock
Keyword Face. Change Height; I used 'scale 3.0'.

You must have been trying to make the font large for the entire
statement? That is also possible in Emacs (it can find a statement),
but that wasn't what I originally proposed.

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Stephen Leake]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Would you care to make that macro available?

(defun ada-comment-box-header ()
  "Create a box comment header for the subprogram name at point."
  (interactive "*")
  (save-excursion
    (let ((subprogram-name (ffap-string-at-point)))
      (beginning-of-line)
      (indent-according-to-mode)
      (insert (make-string (+ 8 (length subprogram-name)) ?-))
      (newline-and-indent)
      (insert (concat "--  " subprogram-name "  --"))
      (newline-and-indent)
      (insert (make-string (+ 8 (length subprogram-name)) ?-))
      (newline)
      (newline-and-indent)
      )))

-- 
-- Stephe

Re: Quick question about Ada code formatting.

[Martin Krischik]

Stephen Leake wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> writes:
> 
>>> If the IDE displayed the keyword 'procedure' (or that whole line) in a
>>> much larger font, would that be easy enough to see?
>>
>> Cool idea, I imedialtly opened my vim configuration and closed it just
>> as fast again.
>>
>> Problem:
>>
>> procedure xxx (
>>   aaaa : bbbb := mmmm;
>>   ccccc: dddd ) renames yyyy;
>>
>> I tried before for syntax folding and failed - Ada's syntax is just to
>> flexible.
>>
>> So you would need a very Ada centric IDE like the GPS to implement that
>> feature.
> 
> Hmph. Emacs can do this easily. Well, it can easily set the font to
> large for _all_ keywords (I just did that, via interactive
> customization). It would not be hard to just set the font to large for
> a subset of keywords.

Not a subset of keywords. vim can do that easily enough - configuring a new
color for every keyword would take about 15 min. The problem is finding the
beginning of a procedure body without false hits on procedure renames and
procedure specifications.

Martin

PS: I started to use vim as it is the best I could get for OpenVMS (emacs
for OpenVMS is outdated and black and white only  - yuck!!! - And we don't
even talk about coosing fonts). But now I actually like it and use it on
Window and Linux as well.
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Quick question about Ada code formatting.

[Georg Bauhaus]

Martin Krischik wrote:

> PS: I started to use vim as it is the best I could get for OpenVMS (emacs
> for OpenVMS is outdated and black and white only  - yuck!!! - And we don't
> even talk about coosing fonts). But now I actually like it and use it on
> Window and Linux as well.

Using Emacs b/w, or any text editing program on a b/w terminal can be a good
way to check one's layout. Like with things that should work at dusk, too,
when the colors vanish.

-- Georg