Re: Code Formatters

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Ole-Hjalmar says

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

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

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

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

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

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

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

This is not an uncommon situation.

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

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

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

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

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

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