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,8811b64ee948c3e3 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Code Formatters Date: 1996/11/05 Message-ID: #1/1 X-Deja-AN: 194675609 references: <552nkb$u1k@gcsin3.geccs.gecm.com> <327A17CA.6B30@gsfc.nasa.gov> organization: New York University newsgroups: comp.lang.ada Date: 1996-11-05T00:00:00+00:00 List-Id: 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.