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=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public 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 From: "Nick Roberts" Subject: Enforcement of coding standards (was: Ada vs C++ vs Java) Date: 1999/01/26 Message-ID: <78j2ck$72f$2@plug.news.pipex.net> X-Deja-AN: 436892817 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> <77q57g$dpu$1@nnrp1.dejanews.com> <36A12D50.9604A0B0@cs.nyu.edu> <77rjbk$7d0@drn.newsguy.com> <77t241$mnj$1@nnrp1.dejanews.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.c++,comp.vxworks,comp.lang.java,comp.lang.ada Date: 1999-01-26T00:00:00+00:00 List-Id: This is a topic we've had before (many times I think) on comp.lang.ada, and Robert Dewar has always made his position very clear (and I mine :-). I disagree with him. I'm not sure if I can successfully argue him round, but I shall try! The essence of my argument is that: (a) it can be harmful to young programmers to expose them to only one style of programming; (b) forcing an unfamiliar style on experienced programmers may reduce their productivity, and can cause resentment; and, most importantly, (c) a standard coding style is never really necessary anyway. I will begin by trying to demonstrate (c) first, in terms of 'answering' one of Dr Dewar's posts. ======================================== robert_dewar@my-dejanews.com wrote in message <77t241$mnj$1@nnrp1.dejanews.com>... |In article <77rjbk$7d0@drn.newsguy.com>, | bill@north.nospam.com.net wrote: |> As for the issue at hand, nowadays there are plenty of |> automated tools to reformat the source code in any shape |> one prefers. so it is not a problem. When you need to |> work on the code, reformat it as you prefer, work |> on it and check it in. The other person can check the |> code later, reformat it as they want and work on it. |> I've done this myself on C/C++ code working with other |> programmers each prefer different way of formating. and |> we never had any problem. | |This is often trotted out as an argument, but it is in |practice bogus for several reasons: | |1. Massive reformatting like this tends to disturb the |sources and not be completely reversible. This will lead |to bogus differences between successive versions, which |cause trouble in practice. The solution to this problem is really simple: don't reformat working code! Furthermore, I would say that it's (normally) rude to reformat another programmer's working code, as well as being a futile exercise. I believe this will be found to held as "programmer's etiquette" all over the world. Furthermore, if a piece of code does need to be reformatted, you only need to 'reregister' it (undelta it, reformat it, redelta it without changing version stamp). If your version control system can't do this, the problem is with your version control system! |2. Many coding rules are not susceptible to completely |automated translation (e.g. going from all upper case to |mixed case identifiers with exceptions for acronyms). The solution to this problem is to impose the minor coding standard that all identifiers are coded in mixed case (if mixed case is required). I've never yet encountered a programmer so bloody-minded as to insist on coding in all upper or all lower case when asked (politely!) not to. Doubtless there is one somewhere. |3. You still have the problem of each programmer having |a distinct style, so code tends to belong to given |programmers, It's never a source of confusion; this is simply not true. Reading code written in a style unfamiliar to me may be slow going for a few minutes, but I become familiar with it very quickly, and it never actually confuses me. Isn't this every programmer's experience? |and the fact that programmers dislike one |another's style is an unnecessary source of confusion and |friction. There's a difference between a programmer preferring a certain style and disliking all other styles. I would suggest that forcing a coding standard on a programmer is likely to be much greater source of friction than having to read code in alternative styles every now and then! |4. Programmer's get careless, and unless this multi-style |approach is truly automated, someone will put code into |someone elses program in the wrong style causing annoyance. On the contrary, if you insert or correct code in someone else's program, you use your own coding style, and they just have to accept it (and you have to accept them doing the same in your code). Again, I think this will be found to be generally accepted programmer's etiquette. Professional programmers don't get careless. As a class, they're the least careless people on the planet. This accusation is the number one reason for programmers chewing right through the skin to the ligament. |5. Ideally, simple things like bracket placement can be |checked with automatic tools that are part of the CM |system, or even the compiler. For GNAT, we have a compiler |option to check style rules, and everyone is required to |use it. Indeed I believe that any code (or at least any Ada code) can be 'beautified' in a totally automated manner, except for the above mentioned problem with identifiers (and certain minor problems with comments, which can also be easily overcome). Thus, if any programmer's code is felt to be just _too_ weird, it can be beautified back into shape in seconds. |All these problems, JUST because some programmer has such |a big ego, or is so stubborn that they can't adopt a simple |set of style rules? Yes! You can sack all your stubborn, egotistical programmers, and I will employ them. And, because I don't impose a coding style on them, they will like working for me, and quite possibly help to make me a rich man (well, that's the theory, anyway :-). But seriously, do you think good (i.e. talented and/or experienced) programmers are never stubborn or egotistical? |In my experience, programmers who are |this individualistic are likely to be poor team members in |any case, In _my_ experience, good programmers tend not to be good 'team members'. It's just one of those facts of life: the psychological factors that lead to a person becoming adept at computer programming tend be the same psychological factors which are associated with an individualistic personality. Which do you want: a good programmer, or a 'team member'? Demanding that a programmer be a good 'team member' strikes me as being rather like a football team demanding that a prospective quarterback is also good at doing tax returns. It may be very fashionable these days, but it's still nonsense. |and as I said in my first post, I simply would |not tolerate this kind of behavior. Perhaps you should try to be a little more tolerant, Robert ;-) |Once again, such |programmers may be the heroes of CMM level 1, but the whole |point of the CMM, even at level 2, is to get rid of this |kind of nonsense! I suspect a lot of people would agree with me that CMM was not written by people who really understand the issues. They may be experts on work methodologies, and many other things, but they are not experts on the realities of programming. ======================================== To expand on point (a), I believe a good employer has a duty to protect the career interests of young programmers. It is almost certainly the case that a young programmer, even if they only ever use one language throughout their entire career, will come to work in many different jobs, departments, and/or projects, and will need to be able to read, understand, and modify other people's code, written to a variety of standards of style (or none). Surely it would be unrealistic to think this will not happen? And, surely, you are not really considering the interests of this programmer unless you allow them to work in an environment where they are likely to be exposed to a variety of different coding styles? Some people may think this is a bit of a concocted point, but it is a serious matter to programmers right at the beginning of their careers. For point (b), I believe it is simply unrealistic to think that you can bring an old, grizzled, programmer into a shop, and expect them to just drop the style of coding they have used for years (even decades) in favour of your preferred style. My specific point is that many (not all) such programmers are certain to be happier, and a little more productive, using the style they prefer and/or are used to. In an earlier post, Robert makes the point that if a programming shop does not impose a coding standard on all its programmers, it is out of control, and badly managed. But, this is not true per se: poor control or management _may_ be a reason for not imposing a single standard, but it is not the only possible reason. It may be that a shop which is being very well managed, and firmly controlled, does not impose a standard as a matter of considered policy. I reiterate, for point (c), that I believe there is never any genuine reason why a single coding standard needs to be imposed on a set of programmers. It is always possible to organise things so that this is not necessary. Whilst it may be easier for the management to make their programmers fit their requirements, rather than bending to the preferences of their programmers, I would go so far as to assert that such a management may actually be demonstrating poorer, rather than greater, control or managerial skill, in giving way to its own laziness, bloody-mindedness, lack of imagination, or even lack of care for its programmers. And finally, I must emphasise that I have the highest regard for Robert Dewar's opinions, and in most computer matters I would readily defer to him. I genuinely have no doubt at all that ACT is run very efficiently, and I do not even begin to argue with the many obvious benefits of using or imposing a standard of coding style in a programming department. I would simply argue that doing so is not necessarily the best policy in all circumstances. ------------------------------------------- Nick Roberts -------------------------------------------