From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,21bbcb8deeeab673
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Ada95 Pretty-Printers/Coding styles
Date: 1997/06/16
Message-ID: <dewar.866484793@merv>#1/1
X-Deja-AN: 248885618
References: <33A54D07.4E14@aisf.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-16T00:00:00+00:00
List-Id: <comp.lang.ada>


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!)