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: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: dewarr@my-dejanews.com Subject: Re: Software landmines (loops) Date: 1998/09/13 Message-ID: <6tglqu$7ab$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 390680567 References: <35DBDD24.D003404D@calfp.co.uk> <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6simjo$jnh$1@hirame.wwa.com> <6sjk3p$4tc$1@hirame.wwa.com> <6skgn4$3gq$1@hirame.wwa.com> <6sm6md$3fh$1@hirame.wwa.com> <35f1375e.6237208@news.erols.com> <35F74AEC.21982C2B@oma.com> <6t937n$ep6$1@nnrp1.dejanews.com> <6telqi$aab$1@nnrp1.dejanews.com> <35FB19F8.D3AAEC2D@earthlink.net> X-Http-Proxy: 1.0 x13.dejanews.com:80 (Squid/1.1.22) for client 209.73.133.253 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Sep 13 14:45:50 1998 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Http-User-Agent: Mozilla/2.02 (OS/2; I) Date: 1998-09-13T00:00:00+00:00 List-Id: In article <35FB19F8.D3AAEC2D@earthlink.net>, Charles Hixson wrote: > dewarr@my-dejanews.com wrote: > > > Some style choices ARE important, but in most agreement is more > important than which style, and in some agreement is the only matter of > importance (and in some, even that isn't important). > I haven't seen anybody defending spaghetti code recently. This is a > (practically universal) style (different things were being optimised), > but agreement wasn't sufficient to maintain it. Whether or not the > names of constants were written in all-caps is a style (actually, it's > one that I, personally, don't like). It is the majority style in some > camps of the computer community (C descendant languages, particularly). > I don't think that it's important as long as that form is not used by > anything else. Any good text editor do a set of global transforms on > the code to match the style of the person who is using it, with NO > IMPACT on anything else (actually, if the header files are shared with > people using differing coding styles, then one set of the constant's > names would need to be defined in terms of the other set of the > constant's names (e.g. #define stdIn STDIN ), but this would only be > needed in languages where the case of the variable name is a semantic > marker, so Ada, for example, wouldn't need a comparable statement > change). > It is incorrect in my view to think that automatic reformatters can solve the problem. First, there are many style rules that are very difficult to automate, especially if they all have an implied "but this does not apply in special cases, and you need human intelligence to determine those cases". Second, if people continue to use their own styles, you still have the phenomenon of balkanization of the coding effort, and people prefer to use their own style. Even if you have a totally invertible transformer, which is in fact difficult to do, for example, the all CAPS style is not automatically convertible to mixed case: It is easy to go from UNIX_Package_Interface to UNIX_PACKAGE_INTERFACE. But it is harder work to go in the opposite direction, you need dictionaries etc. even if you have a totally invertible transformer, people do not feel happy working that way. They tend to maintain private copies of their own code in their own style, and grudgingly convert them to the offical style, feeling that they are destroying them Third, automatic transformers are definitely not good at dealing with conventions for the layout of comments, since these particularly, being natural language dependent have lots of exceptions. Fourth, since so many style rules do have exceptions, unless everyone understands and internalizes the style rules, they do not gather the understanding that is necessary to know when exceptions apply. All in all, between the two models: 1. Everyone in the team uses the same style, and that is what everyone becomes familiar with (it is amazing when you switch styles, how easy it is to get used to a new style -- when I started on the GNAT project, I preferred the Ada 83 style of ALL_UPPER_CASE with underscores, primarily because of the nice automatic separation of identifier names in comments, but the clear majority of programmers on the GNAT project was opposed to this style and now I cannot imagine ever liking it, compared to All_Upper_Case (postscript, I can't imagine every getting to like AllUpperCase, but I expect I would get used to it if I had to). 2. Everyone uses their own style, and automatic tools are used to get some semblance of consistency in the official checked in sources. I think 1 is FAR preferable. Not only does 2 result in real technical problems, e.g. preparing a quick patch to solve a particular bug, but it results in a far less effective level of social cooperation and team cohesion, important factors for the production of quality software. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum