Re: Bad coding standards

[Robert Dewar <robert_dewar@my-deja.com>]

In article <91m2j2$bkn$1@news-hrz.uni-duisburg.de>,
  sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus) wrote:
> I understand that Robert Dewar prefers strict stylistic
> unification, for reasons that he has restated in this
> thread, namely being advantageous for maintanablility,
> and fostering egoless programming.

> What is missing in
> this argument however, is, I think, on what particular
> view this is based.  Is it true that egoless
> programming is a good thing, _economically_?
> The argument is incomplete if it does not show why
> it is preferable

Indeed the argument IS economic:

1. Ease of maintenance is definitely an economic argument. It
is also good for morale. People are going to be forced to
maintain code written by someone else no matter what you do.
It is easier and pleasanter to do this task if the code is
written in a familiar style, which is the style that the
programmer likes to work with.

2. Avoidance of code ownership is most definitely an economic
argument. It is a very dangerous situation for a chunk of code
to be owned by one person. I have time and time again
encountered a situation where even in a large company there
is an important chunk of code which no one can touch, because
only Joe knew the code and Joe left.

> if programmers don't see who wrote what,
> and if programmers are (possibly) forced to write to that
> effect.   I'm reminded of the "Motivation" article in the
> Emacs distribution. If you care about your Ego and connect
> a reason to be proud or satisfied or motivated with your name
> appearing and your style showing up, with the idea in mind.

Pride in code is a very important factor, but that pride can
be shared pride in a team effort. Indeed it is very important
for programmers to be proud of what they create. Within a
team, of course people do know who does what, but from the
point of the external world, it is just fine for the
appreciation to be on the team level.

That has certainly worked well for GNAT, and it is rather
remarkable that at ACT, which has been around for five years,
so far, apart from one person who left to work on GNAT at a
customer site after working for ACT only a few weeks, no
engineer has left ACT. That's unusual in a high tech company
like ours.

Of course there are many reasons for this, but certainly I
don't see at all a situation where individuals are frustrated
by being forced to follow a common style. Quite the opposite.

> that people will be noting this, then Egos programming could
> be an economically relevant factor. Are there measurements?

Well it is very hard to measure this sort of thing, since
other factors are never equal. All I can say is that it works
well for us (Ada Core Technologies).

Note that there are two separate issues here.

1. Common style, I do not see ANY advantage at all economically
or otherwise, in permitting gratuitous variations in coding
style. Anyone who adamantly refuses to follow a common style
is likely to be less than fully cooperative with the team
effort in any case, and the economic disadvantages of not
following a common style are considerable. I know of one
Ada vendor where the binder had a different identifier
capitalization stlye than the rest of the company. The
result was that no one would work on the binder except
this one person, and that was a continual problem.

2. Avoiding code ownership and attribution. This is a different
issue. Common style is necessary to achieve this, but you can
have a common coding style, and still have clear code
ownership. For the reasons I have stated, I think this is
a bad idea, but please don't assume that this is the same
issue as forcing a common coding style -- it is a quite
separate issue.


Sent via Deja.com
http://www.deja.com/