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: 109fba,d95b511473b3a931 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Language Choice and Coding style Date: 1996/07/04 Message-ID: #1/1 X-Deja-AN: 163818672 references: <4quk22$78@krusty.irvine.com> <4r059t$2at0@info4.rus.uni-stuttgart.de> <4r3bp1$cea@Starbase.NeoSoft.COM> <4rg3ph$2on4@info4.rus.uni-stuttgart.de> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1996-07-04T00:00:00+00:00 List-Id: 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