Re: Language Choice and Coding style

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

Peter Herman says

  "I like it to allow everyone to show his personal style.
  This is even important because the motivation is very much higher.
  They are and should keep to be individuals.
  And I like it when I see at first glance "Oh that is the typical
  style of Barbara". This holds for code production inside bodies."

Fascinating to see this point of view expressed so directly (it is I am
sure shared in practice by many programmers).

To me this "ego-centered" style of programming is deadly. It promotes a
situation where in a big project code is owned by individuals. Clearly
if you see that some code is "typical Barbara" style, then the next step
is that only Barbara touches that code, and a consequence is that only
Barbara really looks at that code.

This is not team work, this is a collection of individuals working together,
and you lose the advantages of working as a team. In particular:

   a) If Barbara starts polishing her resume, you can be in big trouble
   b) Only one pair of eyes looks at Barbara's code (other people don't
        because they have their own style they prefer to read).

Furthermore, anyone maintaining the system will find a collection of
different styles that will make it much harder to understand what is
going on.

It's certainly interesting that in the GNAT project, we work hard to achieve
the exact opposite of what Peter regards as acceptable or even desirable.
We work to get complete consistency of sources. This is partly done by
automatic tools (try turning on the -gnatg switch sometimes), and partly
by following a set of standards, which are then informally enforced by
modifications being read by multiple people. You absolutely cannot tell
who wrote code from its style, and indeed we strongly discourage the notion
of authorship (we never for example attach names to units). Sure in practice
certain people know certain code well and our informally the experts in
particular areas, but if you look at the revision histories, you will see
that all sorts of people work in all parts of the system.

In Peter's view of the world, I have too often seen the kind of code
ownership where the owner of the code resents anyone else looking at
their code, let alone modifying it. In GNAT, we strive for and generally
achieve an environment in which your reaction to someone fixing a problem
in code that you wrote is "great, one problem that *I* don't have to fix!"

As for motivation, I think Peter is quite wrong there too. We agree up
front to work as a team. We decide style rules by a vote, but once the
vote is taken that's that. Sometimes it takes a bit of time to get used
to rules. For example, I used to always WRITE_MY_IDENTIFIERS in Ada 83
upper case style (which was the Alsys coding standard), but everyone
else on the team preferred to Write_Their_Identifiers_This_Way, so I
had to change. It took a while to adjust, but now I HATE_THESE_CAPITALS
and Find_This_Style much more natural. The final result is that you
have a team that very much agrees on these style issues, and that
works together as a team. In my experience, as in sports, this team
spirit is a key factor in maintaining a high level of motivation.

Perhaps it is possible to operate a large complex project successfully
with Peter's view, but I have never seen it succeed. On the other hand,
I have seen the team view point work well, both in GNAT and other
projects I have worked on, though I have never seen a project where
the consistency of style achieved for GNAT was as pronounced.

Robert Dewar