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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: dewar@gnat.com Subject: Re: Ada vs C++ vs Java Date: 1999/01/21 Message-ID: <787bv0$gr8$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 435222790 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <369F1D39.64A65BC1@sea.ericsson.se> <369f81a9.31040093@news.demon.co.uk> <77ommt$9bo$1@nnrp1.dejanews.com> <77vhjf$nn9$1@nnrp1.dejanews.com> <77vld9$qvg$1@nnrp1.dejanews.com> <782rp0$kn6$1@nnrp1.dejanews.com> <6Oap2.16170$MW1.4028@news2.giganews.com> <783nnb$s9c@drn.newsguy.com> <784qvi$a0a$1@nnrp1.dejanews.com> <78549k$iqv$1@nnrp1.dejanews.com> <785enu$sq5$1@nnrp1.dejanews.com> X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) X-Http-Proxy: 1.0 x16.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Jan 21 14:01:09 1999 GMT Newsgroups: comp.lang.c++,comp.vxworks,comp.lang.java,comp.lang.ada Date: 1999-01-21T00:00:00+00:00 List-Id: In article <785enu$sq5$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > In article <78549k$iqv$1@nnrp1.dejanews.com>, > robert_dewar@my-dejanews.com wrote: > > In article <784qvi$a0a$1@nnrp1.dejanews.com>, > > dennison@telepath.com wrote: > > (a) no one is arguing in favor of demonstrably silly > > style guidelines. > > Hmm. I didn't find any of those examples *silly*. The > exception is perhaps the leading ';' rule, which was from > an *actual* style guide for a project I worked on. No, the silly thing from your point of view (in your post) was requiring the use of ONE of these in all cases even when it is inappropriate. > > > (b) no one will accept that absurd notion that all > > style guidelines are bound to be demonstrably > > silly. > > Its just as absurd to claim that they are all perfect. Yes, but no one has argued that. You have been arguing against style guide lines all together and then using as your argument examples of silly rules. Please look at your previous posts in the thread, you have made some quite sweeping statements about *all* guidelines. > > If the problem is that there is something wrong with > > the guidelines, fix them, don't ignore them! > > I was on two programs where the style guide was a project > deliverable with a deadline *before* coding started. A very reasonable requirement, and one that should be easy to meet, since any well run shop should have a well tried and true set of familiar guidelines on the shelf. > When silly parts of the guide were stumbled across, it > was not *possible* to go back and change the guide. But as I say, the guidelines should have been established well in advance, furthermore, there are plenty of places to go to get established sets of rules that are known to be workable. Feel free to borrow the ACT ones :-) > > I worked on another with over 100 developers. Any change > to a deliverable > (details on a silly situation snipped) This is not an argument against having a well chosen set of style guidelines. You can't use one example of incompetence to argue against an entire principle. Some people drive cars incompetently, shall we ban all driving as a result? Actually it would be interesting to see from this environment where it is hard to change things whether or not the changes were really justified, or were just people chafing under having to change what they are used to. My experience is that most often it is the latter and not the former. > I take it its not so tough to change the guide where you > work... At this stage, at Ada Core Technologies, it would be almost impossible to make a significant change to our style, since even the smallest change would be very disruptive, both to our common sources, and to everyone's ingrained habits. We do sometimes make changes. For example, we recently fixed our habit of mispelling runtime thus (instead of the proper run-time when used as an adjective). We did this because Digital pointed out this error in our documentation when we were doing the VMS port, and we wanted our sources consistent. This was about as tiny a change as you can imagine, but it required hundreds of files to be updated. We occasionally consider adding new rules, but at this point we are so settled down with our existing set of rules that it is no longer an issue. You would find the situation in most well run shops. Certainly at Alsys the rules had been established early on, and were not an issue (except for the one employee who simply refused to follow them as I mentioned in a previous post). Yes, I can see that if a shop got a project for which coding style rules were a deliverable, and had nothing on the shelf, it would be in trouble, but that's self made trouble caused by incompetent management. You definitely need to iterate and fix and polish to get a workable set of coding rules that will work in your environment. Having to do it in a hurried manner to meet a contract deliverable sounds like a horrible situation to me! Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own