Re: Ada95 Pretty-Printers/Coding styles

Re: Ada95 Pretty-Printers/Coding styles

[Chris Sparks (Mr. Ada)]

I am sure I am going to be flamed for my opinions on pretty printers/
coding styles, however, that's life! :-)

I feel that enforcing strict coding styles on individuals is
unproductive and a source of irritation.  If a company really wants
to have complete 100% consistency, then a tool should be used to
generate company-approved code.  What's even more irritating is when
attending code reviews where most of the discussion is about spacing
and case of identifiers.  Argh!! This may be what is happening at my
company, however, I am sure it happens elsewhere.

Robert states: "Personally I would fire such a programmer,
but that is an extreme position, which many companies are not will to
follow, and instead they tolerate unnecessary variation".

I find this VERY extreme since we humans are not machines and cannot
be expected to work 100% in unison.  Not even the Borg has 100%
commitment among its ranks of automatons!  That is why I feel that
a filter (either a separate tool (Best) or a compiler switch (OK)) is
really one way to assure consistency.

Later...

Chris Sparks

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Chris says

<<I feel that enforcing strict coding styles on individuals is
unproductive and a source of irritation.  If a company really wants
to have complete 100% consistency, then a tool should be used to
generate company-approved code.  What's even more irritating is when
attending code reviews where most of the discussion is about spacing
and case of identifiers.  Argh!! This may be what is happening at my
company, however, I am sure it happens elsewhere.
 
Robert states: "Personally I would fire such a programmer,
but that is an extreme position, which many companies are not will to
follow, and instead they tolerate unnecessary variation".
 
I find this VERY extreme since we humans are not machines and cannot
be expected to work 100% in unison.  Not even the Borg has 100%
commitment among its ranks of automatons!  That is why I feel that
a filter (either a separate tool (Best) or a compiler switch (OK)) is
really one way to assure consistency.>>

Thankyou Chris for giving a nice example of the attitude that I find
unacceptable, and which we would not tolerate for a moment at ACT.
It does not work at all to rely on pretty printing to solve the
problem of divergent styles, because you still have people writing
in their own style, and not being happy working on other people's
code, so you get bad *code ownership* phenomena.

Furthermore, style is much more than a set of mechanical rules wwhich can
be enforced by an automaton, so you will never get realy consistent style
(such as is achieved in the GNAT sources) by this approach.

To get a really cooperative environment, in which everyone looks at every
one else's code and there is as little sense of code ownership as possible,
it is essential that everyone buy into a common style. It is definitely
possible to come close to the ideal of 100% working in unison, and it is
a desirable goal.

I certainly understand Chris's attitude here, since I have run into it often
before, and have seen situations in which companies tolerate this kind of
insistance on personal style. Yes, you may regard my attitude's as extreme,
so you probably would not like to come to work for ACT, but we have certainly
found that lots of people get over their initial irritation at an unfamiliar
style, and end up buying into it with enthusiasm (and the ACT engineers are
all in this category!)

Re: Ada95 Pretty-Printers/Coding styles

[Mats.Weber]

Robert wrote:

> Furthermore, style is much more than a set of mechanical rules which can
> be enforced by an automaton, so you will never get realy consistent style
> (such as is achieved in the GNAT sources) by this approach.

If you have an internal style guide for GNAT code, I'd be interested in
reading it (unless it's a secret recipe, of course :-)

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Mats asks

<<> Furthermore, style is much more than a set of mechanical rules which can
> be enforced by an automaton, so you will never get realy consistent style
> (such as is achieved in the GNAT sources) by this approach.
 
If you have an internal style guide for GNAT code, I'd be interested in
reading it (unless it's a secret recipe, of course :-)>>

The style we use has three parts

a) mechanically enforced rules -- for these see the source files style.ads
and style.adb (which incidentally you can hack to make your own style rules
enforced).

b) rules that are pretty definite, but not enforced, and could be written
down, but never have been. Yes, it would be nice to write these down, but
it is not a high priority task for us.

c) rules that are quite vague, having to do with an aesthetic feeling of
which is the nicer way of doing things in a particular situation. These
cannot easily be written down, but they are a detectable part of the style
of code -- the sort of thing that can give clues as to who wrote the code.

What is remarkable at ACT is that we have a high degree of agreement between
ourselves even at level c). 

I have always looked over every checkin, and made stylistic corrections where
necessary for cases b) and c), and in the old days there were lots of
"minor reformatting" corrections from me, but these days, it is much rarer
for me to make (i.e. to need to make) such corrections, since we all now
have come to a common feel for how to be consistent with the group style.

Re: Ada95 Pretty-Printers/Coding styles

[Jeff Burns]

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

>Mats asks

>If you have an internal style guide for GNAT code, I'd be interested in
>reading it (unless it's a secret recipe, of course :-)>>
>
>The style we use has three parts
>
>a) mechanically enforced rules -- for these see the source files style.ads
>and style.adb (which incidentally you can hack to make your own style rules
>enforced).
>
>b) rules that are pretty definite, but not enforced, and could be written
>down, but never have been. Yes, it would be nice to write these down, but
>it is not a high priority task for us.
>
>c) rules that are quite vague, having to do with an aesthetic feeling of
>which is the nicer way of doing things in a particular situation. These
>cannot easily be written down, but they are a detectable part of the style
>of code -- the sort of thing that can give clues as to who wrote the code.
>
>What is remarkable at ACT is that we have a high degree of agreement
between
>ourselves even at level c). 

Well, the more vague a standard is, the easier it is to have agreement,
right? ;-)

No offense intended Robert, but this sounds very subjective to be much of a
style guide.  It may work at a small company like ACT, and I understand your
code is beautiful, so it does work for you.  But this model doesn't sound
very reasonable for large defense and aerospace companies where thousands of
engineers are working on hundreds of projects (and where staffing is
inconsistent and people work in multiple languages).  Vague aesthetics and
individual interpretation of good style are not consistent with an
engineering approach to large scale complex manufacturing (which is what
they're doing).  Their code needs to be understandable, not just internally,
but to their customers and to other contractors who may have to maintain or
update their code.

We at GrammaTech work with a lot of engineers who have to work with code
they've inherited from other contractors.  You'd be amazed at how
inconsistent and difficult to read this code often is.  It seems to be a
fairly universal problem.  At tradeshows we bring one of the worst examples
of source code we've found and use it for a "before and after" demo of how
Ada-ASSURED can pretty print, clean up style problems, and help standardize
multiple source files.  Nine times out of ten the engineers we demo it to
tell us they've had to work with code that's as bad or worse than our
"before" example.

I'm confident that there are internal style guidelines at the organizations
that produce code like our "before" example.  But for whatever reason, style
guidelines are not always enforced, people seem to go in their own
directions, and the results are not the consistent quality that ACT is able
to produce.

With Ada-ASSURED we're trying to help engineers to follow consistent style
guidelines across group, project, and company boundaries so their code will
be easier for anyone to read.  As you have mentioned, consistency is a key
objective.  However, I understand from your past postings that you often
find tools that enforce a consistent coding style too restrictive.

Ada-ASSURED helps monitor, enforce, and correct code according to very
specific style guidelines based on the AQ&S, the LRM, and common correct
usage we learn from our customers. We balance standardization with
flexibility where we can. A lot of the guidelines can be turned on/off or
parameterized for a project's preference or interpretation, but others are
less flexible and may be considered restrictive (it is the nature of
standards to be specific and this is can be restrictive).  Ada-ASSURED takes
care of style, automatically much of the time, so engineers can concentrate
on more challenging and important things, like content.  This approach may
not be for everyone, but the alternative, from what I've seen, is often not
very pretty and costs extra time and money down the road.

-----------------------------
Jeff Burns, Director of Marketing
GrammaTech, Inc.
One Hopkins Place
Ithaca, NY  14850
ph: 607-273-7340
fax: 607-273-8752
e-mail:  jeff@grammatech.com
www:  http://www.grammatech.com
Team Ada
==============================

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

In an advertisement for Ada Assured we read

<<No offense intended Robert, but this sounds very subjective to be much of a
style guide.  It may work at a small company like ACT, and I understand your
code is beautiful, so it does work for you.  But this model doesn't sound
very reasonable for large defense and aerospace companies where thousands of
engineers are working on hundreds of projects (and where staffing is
inconsistent and people work in multiple languages).  Vague aesthetics and
individual interpretation of good style are not consistent with an
engineering approach to large scale complex manufacturing (which is what
they're doing).  Their code needs to be understandable, not just internally,
but to their customers and to other contractors who may have to maintain or
update their code.>>

I suspect you have not read any of the material here and are just guessing.
In fact the kind of mechanical rule that Ada Assured can enforce IS enforced
by a mechanical tool at ACT, namely the -gnatg switch, and the documentation
of these requirements is very precise, it can be found in the files style.ads
and style.adb.

These rules are by no means trivial, they include things like

a) specs required for all procedures
b) capitalization in a use of an identifier must match the declaration


(I choose these two, because they need quite a bit of semantic help from
the compiler, i.e. these rules are not trivial syntactic gizmos alone, 
though trivial syntactic gizmos are included -- although even there, I fined
that many tools I have seen would be incapable of enforcing our commenting
layout standard).

So, yes, I agree that tools like Ada Assured are useful, however, for maximum
utility I think it is important that they be embedded into the compiler, and
not separate from it for two reasons:

1. For some of the more subtle stuff, you need the full power of an Ada
compiler anyway.

2. That way, it is easy to insist on its absolutely systematic use. In our
environment it is simply not possible to check in code that has not been
checked out by this tool, and that comes not from some barrier at the
checkin stage, but because EVERY compilation ALWAYS checks.

The points in my note that you identified as vague go FAR beyond anything
that can be done automatically by a tool. 

And yes, I agree, it is probably impossible to get a large company to
apply this kind of consistency company wide, but that is not necesarily
a requyirement, the more important thing is to apply this kind of uniformity
to a single project, or at least to a single large component of a project.

Re: Ada95 Pretty-Printers/Coding styles

[nma123]

In article , "Jeff says...
>
>
>-----------------------------
>Jeff Burns, Director of Marketing
>GrammaTech, Inc.
>One Hopkins Place
>Ithaca, NY  14850
>ph: 607-273-7340
>fax: 607-273-8752
>e-mail:  jeff@grammatech.com
>www:  http://www.grammatech.com
>Team Ada
>==============================
>

hi, I looked at your web page about Ada-Assured smart editor for Ada.
I was not able to see any examples of how it looks, it would be nice
to put some images show how the editor looks. I was not able to find
anywhere anything about how much it costs.

And one of your web pages was hard to read, you have strong blue
background on it which made it hard to read the text on it.

thanks,
Nasser Abbasi

Re: Ada95 Pretty-Printers/Coding styles

[Jeff Burns]

>I looked at your web page about Ada-Assured smart editor for Ada.
>I was not able to see any examples of how it looks, it would be nice
>to put some images show how the editor looks. I was not able to find
>anywhere anything about how much it costs.

Thanks for the feedback Nasser.  You're right.  I'll add some sample screen
shots and a "before and after" example to demonstrate the pretty printer.

The price of Ada-ASSURED is $1,995 per floating license for Unix platforms.
The NT version will be less, but the price hasn't been finalized yet.  Keep
in mind that Ada-ASSURED is much more than just an editor.  It's a
multi-purpose tool that knows the rules and structure of Ada 95 and Ada 83.

There are some less expensive LSEs out there, but they are incapable of
doing incremental syntax analysis, true syntax coloring (as opposed to
lexical coloring), Ada structure editing, code transformations, Ada style
checking, or high quality pretty printing comparable to Ada-ASSURED. When
you think of the engineering time spent in these areas, AA pays for itself
very quickly and saves time and money down the road because code will be
easier to understand and maintain. 

Ada-Utilities is a new product coming out this summer for auditing and
processing multiple files at once (and for sites that don't need a new
programmer's editor).  The toolset includes: Ada-Audit, Ada-Prettyprint, and
Ada-Transform (this is like a language-sensitive awk, sed, or grep for Ada
that enables global editing that would otherwise be impractical to attempt).
 It will be $7,995.

Thanks,

Jeff

P.S.  I'll fix the bad background on the web page you mentioned. Sorry about
that.

-----------------------------
Jeff Burns, Director of Marketing
GrammaTech, Inc.
One Hopkins Place
Ithaca, NY  14850
ph: 607-273-7340
fax: 607-273-8752
e-mail:  jeff@grammatech.com
www:  http://www.grammatech.com
Team Ada
==============================
Ada-ASSURED
	LSE
	Style Standards Enforcer
	Browser
	QA Tool
	Code Transformer
"Cure for the Common Code"
==============================

Re: Ada95 Pretty-Printers/Coding styles

[Shmuel (Seymour J.) Metz]

A tool that forces people to use a standard style is not nearly as
valuable as
one that makes it easy for them to do so. Your web page talks about
enforcing
style, but doesn't mention automating it. If your LSE does indeed
provide for
assiting in entry of properly indented and delimited code, that's worth 
mentioning explicitly; if it doesn't, I question the value of the
product, 
especially since much less expensive LSEs are capable of doing that.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Seymour says

<<A tool that forces people to use a standard style is not nearly as

valuable as

one that makes it easy for them to do so. Your web page talks about

enforcing

style, but doesn't mention automating it. If your LSE does indeed

provide for

assiting in entry of properly indented and delimited code, that's worth

mentioning explicitly; if it doesn't, I question the value of the

product,

especially since much less expensive LSEs are capable of doing that.>>


Peronsally I hate editors that try to help me with style, but for those who
lie this, of course Ada mode in EMACS has always had this capabilty.

Re: Ada95 Pretty-Printers/Coding styles

[jeff]

In article <33BBEC62.5F16@gsg.eds.com>,



  nospam@gsg.eds.com wrote:







> Your web page talks about enforcing style, but doesn't mention automating it. > If your LSE does indeed provide for assiting in entry of properly indented and > delimited code, that's worth mentioning explicitly; if it doesn't, I question > the value of the product, especially since much less expensive LSEs are

> capable of doing that.







Looking at the Ada-ASSURED web page from your perspective I can see how
it  might sound a little heavy handed on the "enforcement" side and
doesn't say enough about how it automates formatting and style.  I will
keep this in mind as we update our web site this summer.







To be more explicit, as you suggest, Ada-ASSURED does automate formatting
for you, so you don't have to think about spaces and tabs any more (or
about capitalization of identifiers, which can be controlled by
syllable).  Furthermore, if you make a style error, like try to put in
too many nested loops or enter an illegal goto for example, Ada-ASSURED
will provide a warning message as a comment in your code (warnings are in
three levels of severity: indicator, violation, and syntax error) or
optionally in a separate window.  This is what is meant by "enforced." 
Ada-ASSURED doesn't stop you dead in your tracks, but it lets you know
where problems are.







Ada-ASSURED's automatic formatting follows the SPC AQ&S, but it can be
modified for project-specific requirements.







It differs from other so-called LSEs you refer to in several ways:







1.  Ada-ASSURED understands Ada 95 and Ada 83 structure, enabling
engineers to edit code structures as easily as they edit text.	This
gives engineers another arrow in the quiver for editing code faster and
with fewer errors.  AA underlines the Ada structural unit surrounding the
cursor.  An Ada structure can thus be selected for cut and paste
instantly without having to scroll from the beginning to the end of the
structure -- AA knows where it begins and ends	(even for structures
spanning several pages) and never misses a character.  This is real
language-sensitive editing.  Of course, conventional text editing (along
with textual cut and paste) can be done at the same time:  Ada-ASSURED is
a hybrid text and structure editor.







2.  AA formats your code as you type it in.  AA formatting optimizes
available window real estate for readability.  If you change your window
width, the code is reformatted to fit the window and with correct
indentation.  This way you could have multiple windows opened and resize
them as you wish and it will still be easy to read all your code.  Other
editors can't do this.







3.  AA does true syntax coloring, not the more rudimentary lexical
coloring of Emacs Ada mode and various "programmer's editors."	True
syntax coloring is more complete and accurate, so it's easier to read and
understand code.







4.  AA can do structural search and replace.  You can search for a
particular structure.  Other editors don't offer this precision, which
can be a real time-saver.







5.  AA provides context-sensitive templates.  The templates it offers are
context-sensitive to the structure where your cursor is located, so only
the templates you might need are offered.  AA templates are syntactically
correct skeleton code with placeholders that can be quickly filled in. 
AA templates can be selected via the mouse or through simple key
commands.  Another time-saver that also reduces errors.  Other editors
may have templates, but you've got to search to find the one you want.







6.  AA includes language-sensitive scripting.  The scripting language is
similar to Emacs; one big difference is that AA provides direct access to
the structure of your code, so you can write very precise code
transformations etc.







There's more, but I've surely gone far enough commercially in this
posting.  Back to your posting:  yes, there are cheaper LSEs, but they
aren't really language-sensitive.  They are text editors with lexical
coloring and hard-written templates.  Ada-ASSURED is a true
language-sensitive editor (GrammaTech's founders pioneered
language-sensitive editing at Cornell University back in the 70s). 
Ada-ASSURED pays for itself through increased productivity, fewer errors,
and beautiful looking code.  It continues to pay for itself down the road
because your code will be easier to read and understand, and therefore
easier to maintain and reuse.







Some folks don't like the concept of language-sensitive editing. 
Similarly, I know some people don't like word processors and would rather
use a pen and paper.  The end product can be the same either way I
suppose.  A word processor or a good LSE just makes it easier to get
there, they can catch some errors along the way, and they can
automatically ensure consistency.











"Technology will allow us to be whatever we are already, only more so."







-- Arno Penzias

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Jeff said

<<Looking at the Ada-ASSURED web page from your perspective I can see how
it  might sound a little heavy handed on the "enforcement" side and
doesn't say enough about how it automates formatting and style.  I will
keep this in mind as we update our web site this summer.
>>

However, one conclusion from our discussions was that the kind of processing
that Ada-ASSURED can do is not sufficient for our purposes. In particular,
two of the checks which we consider essential (separate specs required
for all subprograms, and spelling of identifiers required to be consistent
with the matching declaration) seem beyond its reach.

It is for this sort of check (we have in mind a number of similar semantic
checks), that it seems more effective to embed a formatting tool into the
compiler, or, perhaps as an alternative, build an ASIS-based tool for
performing the checking.

Of course this does not give you on the fly editing assistance. Some people
like this, and indeed the Ada modfe we supply for EMACS precisely does those
simple syntactically driven formatting rules automatically, but currently
does not go further than this (although interestingly, EMANCS is hooked into
the gnatf xref output, and using this interface, it is not impossible to do
some of the semantic checking, certyainly the above two rules are in reach).

Jeff you never really confirmed that the two cases above are ones that
Ada-ASSURED could not handle. At first you said that the identifier

consistency case could be handled, but I think this was based on a 
misundestanding that I was talking simply about enforcing a consistent
casing style, and I was talking about something quite different.

Robert

Re: Ada95 Pretty-Printers/Coding styles

[nickerson]

In article <dewar.866484793@merv>, 
dewar@merv.cs.nyu.edu (Robert Dewar) writes:
..
|>To get a really cooperative environment, in which everyone looks at every
|>one else's code and there is as little sense of code ownership as possible,
|>it is essential that everyone buy into a common style. It is definitely
|>possible to come close to the ideal of 100% working in unison, and it is
|>a desirable goal.
..
??? code ownership is bad, one can't work on or understand or appreciate
code not in ones own style, differences in style significantly negate 
cooperation, working 100% in unision requires a common style ???

is all of that really the ACT (or your) philosophy; to me it starts 
looking like you believe that form is the only cohesive force;

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Bart said

<<is all of that really the ACT (or your) philosophy; to me it starts
looking like you believe that form is the only cohesive force;
>>

Bart, the "only" here is pure invention on your part. What I have said
is that a common coding style is important. For you to conclude that
it is the only important form in having a highly cohesive group is

(a) most peculiar

(b) completely inconsistent with anything I have said

I think that commonality of style is necessary to get a really cooperative
environment that effectively eliminates the notion of code ownership (I
certainly have never seen this achieved in an environment without a
strong sense of common style).

However, to suggest that it is sufficient seems, as I say, most peculiar.

But in answer to your first question, yes, the quotation definitely does
reflect ACT philosophy. The rest of the sentence after the semicolon comes
from your own experience and feelings, not from ACT!

Re: Ada95 Pretty-Printers/Coding styles

[Jeff Burns]

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

>In an advertisement for Ada Assured . . .

Hmm, seems I have seen ACT mentioned here once or twice, too. ;-)

That's okay.  Tool support is one of the major criticisms of Ada, so it's
worthwhile letting engineers know what good Ada tools are available.

Got your point, however, and will try not to stray too far over to the dark
side of commercialism.

>I suspect you have not read any of the material here and are just guessing.
>In fact the kind of mechanical rule that Ada Assured can enforce IS
enforced
>by a mechanical tool at ACT, namely the -gnatg switch, and the
documentation
>of these requirements is very precise, it can be found in the files
style.ads
>and style.adb.

I have read a fair amount of material here and noted that when someone asked
you for your specific coding style, you listed three items, two of which you
described as undocumented or vague.

The other item you mention above is a mechanical check of 31 GNAT style
rules using the -gnatg switch with the GNAT compiler. I have looked at these
rules and they are an extremely small subset of a typical set of style
guidelines and do not begin to address many of the SPC's Ada Quality and
Style Guidelines enforced by Ada-ASSURED.

===
Software Productivity Consortium AQ&S
http://sw-eng.falls-church.va.us/AdaIC/docs/style-guide/95style/html/cover.h
tml
===

>
>These rules [style.ads and style.adb] are by no means trivial,
>they include things like
>
>a) specs required for all procedures
>b) capitalization in a use of an identifier must match the declaration

This is interesting because the second example you give IS trivial, at least
for Ada-ASSURED, and not to just monitor this style but to actually automate
compliance.

In fact, all but two of the 31 rules in your style files are trivial for
Ada-ASSURED.  And then, of course, it goes much further to automate many
more rules and guidelines from the AQ&S and the LRM.

The other two rules, including the first example above are good uses for a
compiler.

>So, yes, I agree that tools like Ada Assured are useful, however, for
maximum
>utility I think it is important that they be embedded into the compiler

Here's where we differ. Our approach is that AA takes care of formatting and
style checking while the code is being written (or just after it's written
or received, in the case of Ada-Utilities), so fewer style errors (and no
syntax errors) ever reach the compiler.  This helps reduce
compile/correction/recompile cycles.

Your approach delays this kind of error checking until code reaches the
compiler.  It seems to me it would add a lot of overhead to the compiler. 
And, of course, a compiler wouldn't actively correct style and formatting
errors, it would just check for errors.

>1. For some of the more subtle stuff, you need the full power of an Ada
>compiler anyway.

Agreed, some of the more subtle stuff is best handled by the compiler.

>2. That way [embedding style checking into the compiler], it is easy to
insist
>on its absolutely systematic use. In our
>environment it is simply not possible to check in code that has not been
>checked out by this tool, and that comes not from some barrier at the
>checkin stage, but because EVERY compilation ALWAYS checks.

While I understand the appeal of this hypothetical approach for universal
checking of code, it is a passive solution that adds unnecessary additional
work.  The compiler finds errors and then the original engineer (or worse
yet, someone else) has to manually go back through the code and make
corrections.

Furthermore, the 31 GNAT rules are hardly comprehensive.  Certainly you
aren't suggesting that every compiler should be burdened with a complete set
of style checks and a multitude of formatting checks (such as colon and
identifier alignment).

These items are more easily handled by a tool designed for checking and
correcting style.

>The points in my note that you identified as vague go FAR beyond anything
>that can be done automatically by a tool.

But how would we know if, as you said, they are not documented?  The very
best of objectives don't mean much in most organizations if they're not
documented -- how important can they be if they're not written down? 
[Granted, you run a tight shop where this informal approach works well among
your small number of engineers.]

I don't know which of your undocumented style guidelines can be automated,
but so far you seem to have underestimated what can be done automatically by
a tool (ironic, coming from a compiler vendor).
 
>And yes, I agree, it is probably impossible to get a large company to
>apply this kind of consistency company wide

This is where a tool like Ada-ASSURED comes in:  it can apply a consistent
style company wide.  It may not ensure compliance with every nuance your
group has informally selected, but it will ensure consistent conformance
with a customizable and reasonably comprehensive set of style guidelines.

We agree that following a consistent coding style contributes to quality: 
code will be easier to read and understand, and therefore easier to maintain
and reuse.  We differ in practical approaches for getting there.

-----------------------------
Jeff Burns, Director of Marketing
GrammaTech, Inc.
One Hopkins Place
Ithaca, NY  14850
ph: 607-273-7340
fax: 607-273-8752
e-mail:  jeff@grammatech.com
www:  http://www.grammatech.com
Team Ada
==============================

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Jeff Burns said

<<>In an advertisement for Ada Assured >>

  I wasn't objecting to the advertisement, the line is sometimes tricky, but
  I don't think you crossed it. No one minds mild advertising on CLA if it
  contains useful technical information (it does tend however to be 
  non-objective advocacy -- but if we disallowed non-objective advocacy,
  half of CLA would disappear!)

<<The other item you mention above is a mechanical check of 31 GNAT style
rules using the -gnatg switch with the GNAT compiler. I have looked at these
rules and they are an extremely small subset of a typical set of style
guidelines and do not begin to address many of the SPC's Ada Quality and
Style Guidelines enforced by Ada-ASSURED.>>

  The point is that all the rules that we need enforcing mechanically ARE
  enforced by -gnatg. Yes, of course anything else could easily be added
  to -gnatg, but most of the rules in AW&S are guidelines, not suitable
  for 100% automatic enforcement (remember that for us a program that
  violates the -gnatg rules is illegal).

This is interesting because the second example you give IS trivial, at least
for Ada-ASSURED, and not to just monitor this style but to actually automate
compliance.

  It is not technically trivial, since it requires complete and accurate
  overloading and visibility analysis in the style conformance tool. If
  you are saying that Ada Assured fully understands Ada overloading and
  visibility rules, that's fine, but then you would be the first to
  agree this is not trivial, since this requires a lot of the most
  difficult processing that a compiler has to do. Furthermore, it is
  tricky to do this in an ancillary tool that is not a compiler, since
  you cannot run the ACVC suite to make sure that you have a reasonably
  accurate implementation of the overloading algorithm.
                              
<<Your approach delays this kind of' error checking until code reaches the
compiler.  It seems to me it would add a lot of overhead to the compiler.
And, of course, a compiler wouldn't actively correct style and formatting
errors, it would just check for errors.>>

  Nope, the overhead added to the compiler is unmeasurable. That's because
  almost all of the processing has to be done anyway. On the contrary doing
  it with a separate tool *does* add a lot of overhead. I am quite surprised
  by your claim that Ada Assured does full overloading and visibility 
  analysis. I certainly do not think that this can be done at zero cost.

<< Agreed, some of the more subtle stuff is best handled by the compiler.>>

  I am surprised that overloading and visibility analysis are not in this
  category for you. Ada Assured must be nearer to a compiler than I thought.

<<While I understand the appeal of this hypothetical approach for universal
checking of code, it is a passive solution that adds unnecessary additional
work.  The compiler finds errors and then the original engineer (or worse
yet, someone else) has to manually go back through the code and make
corrections.>>

  Actually it is rare for the compiler to find an error, since the ACT
  team has internalized the rules a long time ago, and new people coming
  aboard very quickly learn to as well. The point is that writing in
  GNAT style involves MUCH more than these 31 rules, and in particular
  involves learning all sorts of stylistic approaches that cannot possibly
  be automatically checked.

  Basically the 31 rules we check are all the rules that we apply absolutely.
  We have many other rules, but no automatic tool has a feel for when
  exceptions are allowed (which is fairly frequently).

  It is never the case that someone else has to find the errors. Our 
  procedures make it absolutely impossible for someone to check in a unit
  that is illegal. And as I noted before, style violations (of these 31
  rules) are considered illegalities.

<<These items are more easily handled by a tool designed for checking and
correcting style.>>

  On our list of things to do for GNAT is to grealy extend both the
  set of possible style checks, and the ability to control them. Our
  design for this will allow customization at roughly the level supported
  currently by Ada Assured (although I am still a little puzzled at the
  claim about overloading, perhaps AA has capabilities that I am unaware
  of from the demos and reading I have done). 

  Yes, of course these are after-the-fact checks, and a separate tool
  for enforcing these as you go along would be useful (preferably this
  tool should be embedded into an editor, so it also is used automatically,
  though it is important to realize that many people hate such intefering
  editors. I personally cannot stand them, but many people like them also.

<<This is where a tool like Ada-ASSURED comes in:  it can apply a consistent
style company wide.  It may not ensure compliance with every nuance your
group has informally selected, but it will ensure consistent conformance
with a customizable and reasonably comprehensive set of style guidelines.>>

  At ACT, the compiler already enforces all the rules that we regard as
  mechanically enforcable (actually there is one minor exception, to be
  added in some release in the near future). However, it is what you
  write off as "minor nuances" that we regard as the essential and
  important elements of style.

  If your only mechanism for style consistency relies on mechanical
  checking, then you will fall far short of the goal that we have
  set for ourselves in stylistic consistency at ACT.

Re: Ada95 Pretty-Printers/Coding styles

[Robert Dewar]

Jeff Burns said

<<>These rules [style.ads and style.adb] are by no means trivial,
>they include things like
>
>a) specs required for all procedures
>b) capitalization in a use of an identifier must match the declaration

This is interesting because the second example you give IS trivial, at least
for Ada-ASSURED, and not to just monitor this style but to actually automate
compliance.
>>

Rereading this, I am almost certain that you misread b) to be talking about
a consistent capitalization style. Which is indeed trivial.

This is much more subtle, since it handles visibility and overloading in
GNAT:

     1. procedure q is
     2.    procedure Printf (X : String);
     3.    procedure Printf (X : String) is
     4.    begin
     5.       null;
     6.    end Printf;
     7.
     8.    procedure printf (X : Integer);
     9.    procedure printf (X : Integer) is
    10.    begin
    11.       null;
    12.    end printf;
    13.
    14.    S : String (1 .. 3);
    15.    I : Integer;
    16.
    17. begin
    18.    Printf (S);
    19.    printf (S);
           |
        >>> (style) bad identifier casing, should be "Printf"

    20.    Printf (I);
           |
        >>> (style) bad identifier casing, should be "printf"

    21.    printf (I);
    22. end q;

I chose printf as the name here, because the convention in GNAT when
importing functions from C is to use the C capitalization (we do NOT
have any consistent 100% enforced rule for capitalization -- we have
strict rules, but they are a bit subtle, and beyond the easy reach
of a tool).

Are you really sure that Ada Assured regards the above as "trivial"

And if so, surely enforcing the presence of specs (something that we
really *do* want enforced mechanically) is even more trivial no?

Re: Ada95 Pretty-Printers/Coding styles

[Wes Groleau]

> >b) capitalization in a use of an identifier must match the declaration
> 
> This is interesting because the second example you give IS trivial, 

Any pretty-printer or style-checker cannot enforce _semantic_ rules 
like this unless it builds (in a library like many Ada compilers or
on-the-fly like GNAT) a multi-source-file symbol table.  When I used
Ada-ASSURED years ago, it was able to do what it did on a single file,
with no need to look at any other file.  Therefore, it could not do
the above.  A related example: The project had decided to use 
Initial Caps for variables and constants, ALL CAPS for subprograms.
This rule was changed when Ada-ASSURED came along, because it could
not distinguish a function call from an array element.

PLEASE don't condemn the tool for what I just said.
It could have changed in 2-3 years, and besides, the 
syntactic approach does have its own advantages.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada95 Pretty-Printers/Coding styles

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> I think that commonality of style is necessary to get a really cooperative
> environment that effectively eliminates the notion of code ownership (I
> certainly have never seen this achieved in an environment without a
> strong sense of common style).

I've been in cooperative environments, and never has it been necessary
to tell
the programmers to adopt a common style and code in lock step. If that's
the only
way that you can get cooperation then there's something wrong with your
managers or your programmers, probably both. Further, I know of no
evidence that eliminating the sense of code ownership is desirable, or
even benign.

That said, there are several areas where. IMHO, uniformity is desirable.
A common set of tools allows the programmers to easily interchange data
and enhancements to the tool set. A programmer modifying an existing
procedure should adhere to the existing conventions for, e.g.,
indentation, in order to keep it cohesive.

As to a sense of ownership, I believe that it leads to pride in
workmanship provided that it is not used as an excuse for maintaining an
exclusive lock on the code or an
immature and unprofessional resentment of anyone who finds a problem in
it. But the latter problem, in my experience, is more likely when the
entire group regards the code as collectively theirs than when
"ownership" is vested in just one programmer.

I but software from small developers and from large corporations. The
small developers generally have a sense of ownership, and they are
generally very responsive to problem reports. The large corporations,
for the most part, have institutional ownership of the code and
stonewall when problems are reported.

Of course, there are exceptions: lousy personal support and good
institutional support. But those are in the "man bites dog" category.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

The opinions expressed are my own, and do not necessarilly reflect those
of my
employer, my spouse, my children or my PC.

Re: Ada95 Pretty-Printers/Coding styles

[Stephen Garriga]

On 16 Jun 1997 14:19:07 -0400, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>Chris says
>
>>I feel that enforcing strict coding styles on individuals is
>unproductive and a source of irritation.  {SNIP}.....
>
>Thankyou Chris for giving a nice example of the attitude that I find
>unacceptable, and which we would not tolerate for a moment at ACT.
>It does not work at all to rely on pretty printing to solve the
>problem of divergent styles, because you still have people writing
>in their own style, and not being happy working on other people's
>code, so you get bad *code ownership* phenomena.
There is a big difference between people having their own syle, and
not wanting to work on other peoples 'differently styled' code. That's
like saying you can't enjoy reading a book that you did not write!

>
>Furthermore, style is much more than a set of mechanical rules wwhich can
>be enforced by an automaton, so you will never get realy consistent style
>(such as is achieved in the GNAT sources) by this approach.
Yes, but much of what causes problems is personal layout options; tabs
vs. spaces, indent levels, variable case etc.

>
>To get a really cooperative environment, in which everyone looks at every
>one else's code and there is as little sense of code ownership as possible,
>it is essential that everyone buy into a common style. It is definitely
>possible to come close to the ideal of 100% working in unison, and it is
>a desirable goal.
It is the nature of my work that I have to look at many peoples code,
each (suposedly) following a set of standards and conforming to a
style guide, however there is still a variety in 'style'. There are
often many ways of doing the same thing, unless you have every coder
incapable of aberent/creative thought (i.e. all coders are (mentally)
identical clones or brainwashed to the same end) you will still end up
with different 'styles'.

>
>I certainly understand Chris's attitude here, since I have run into it often
>before, and have seen situations in which companies tolerate this kind of
>insistance on personal style. Yes, you may regard my attitude's as extreme,
>so you probably would not like to come to work for ACT, but we have certainly
>found that lots of people get over their initial irritation at an unfamiliar
>style, and end up buying into it with enthusiasm (and the ACT engineers are
>all in this category!)
I would rather code were clear (self documenting) than following a
rigid set of rules. People are individuals and should be allowed to
act as such. I for one would not work for a company that insisted I
wore a suit every day, or that I must be clean-shaven. By the same
principle I could not work for a company that wanted me to be a
trained dog to jump through hoops or a mindless automaton!

Steve Garriga                         garriga@logica.com                 
   type OPINION is access PERSONAL_THOUGHTS_AND_BIAS; 
   OPINION_STATED : new OPINION := not LOGICA.OPINION;
Logica UK Ltd.   +44 171 637 9111   http://www.logica.com

Re: Ada95 Pretty-Printers/Coding styles

[Chris Sparks (Mr. Ada)]

Robert responded with:

> Thankyou Chris for giving a nice example of the attitude that I find
> unacceptable, and which we would not tolerate for a moment at ACT.
> It does not work at all to rely on pretty printing to solve the
> problem of divergent styles, because you still have people writing
> in their own style, and not being happy working on other people's
> code, so you get bad *code ownership* phenomena.

Well I can relate to this statement.  If a programmer isn't as
persnickedy (sp?)
as I am, then looking at their code can be a chore in itself!  The most
offensive Ada code I have seen have come from "C/C++" programmers who
are
forced to use Ada.  Yuch!

> Furthermore, style is much more than a set of mechanical rules wwhich can
> be enforced by an automaton, so you will never get realy consistent style
> (such as is achieved in the GNAT sources) by this approach.

Well you may have a point here.  I have seen your "sources" and found
them
easy to follow.  Your organization is as persnickedy as I am.  On no!
:-)

> To get a really cooperative environment, in which everyone looks at every
> one else's code and there is as little sense of code ownership as possible,
> it is essential that everyone buy into a common style. It is definitely
> possible to come close to the ideal of 100% working in unison, and it is
> a desirable goal.

We can abstract this concept a little further in that most programmers
will
code to a established well-defined (personal) style.  I don't believe
that
they would change their style continually in their software.  Once a
look-and-
feel has be attained, then most programmers stick with it for years.
Look
at the Ada 83 LRM's style.  I programmed in upper case for a long time.
Now
I can't even look at uppercased code.  I say to myself "Why is this
person
shouting?!" :-)  Anyway, your point is valid.  Maybe what I am so
uptight about
coding standards may not lie in the standards itself, but in the process
itself.

> I certainly understand Chris's attitude here, since I have run into it often
> before, and have seen situations in which companies tolerate this kind of
> insistance on personal style. Yes, you may regard my attitude's as extreme,
> so you probably would not like to come to work for ACT, but we have certainly
> found that lots of people get over their initial irritation at an unfamiliar
> style, and end up buying into it with enthusiasm (and the ACT engineers are
> all in this category!)

I am used to abiding to a company's coding standard.  I may like my own,
however,
I am paid to do what they want!  With regards to "coming to work for
ACT", I would
LOVE the opportunity to work for your company, coding styles and all.
:-)  I am a firm
believer that once we get past what is expected (code look and feel)
than we can get
down to some serious programming.  I always say that what is most
important is
the code.  If it isn't right, no amount of style is going to help it!

Later...

Chris Sparks

Re: Ada95 Pretty-Printers/Coding styles

[Geert Bosch]

Mr. Ada <sparks@AISF.COM> wrote:

 ``Well I can relate to this statement.  If a programmer isn't as
   persnickedy (sp?) as I am, then looking at their code can be a
   chore in itself! ''

In this case you should be extremely persnickety about spelling
words correctly.

Regards,
   Geert

Re: Ada95 Pretty-Printers/Coding styles

[Chris Sparks (Mr. Ada)]

Geert Bosch wrote:

> In this case you should be extremely persnickety about spelling
> words correctly.

Maybe I am not a persnickety as I thought I was! :-)  Thanks for
correcting my spelling.  I didn't have a dictionary at hand.

Later...

Chris Sparks