Xref: utzoo comp.lang.c:14794 comp.unix.wizards:13487 Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!pacbell!pbhyf!mche From: mche@pbhyf.PacBell.COM (Mitch Che) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Standards (was Re: indentation: enough already!) Message-ID: <4402@pbhyf.PacBell.COM> Date: 15 Dec 88 19:28:32 GMT References: <3229@ingr.UUCP> <253@athertn.Atherton.COM> <3245@ingr.com.> Reply-To: mche@pbhyf.PacBell.COM (Mitch Che) Organization: Pacific * Bell, San Ramon, CA Lines: 36 In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: >deciphering other coding styles. On the flip side, I must admit that I >have also seen some VERY poorly written code (no comments, one letter global >variables, etc). The point I am trying to make here is that left alone good >programmers write good code and bad programmers write bad code. What is >needed instead of stringent "standards" is a well thought out education plan >whose goal is to make good programmers out of bad ones... Left ALONE, 50 programmers will come up with 50 different reasons why the other 49 programmers should do it THEIR way. Education is necessary. Unfortunately, many times the ones who are most educated, the "experts", regress and become "bad" programmers. A story: In a previous job, I worked with Fortran and APL. The expert programmers would compete to come up with the longest Fortran program in the world that could be converted to one line of APL. The result was typically something so obsure that even the author couldn't figure out what the APL code really did without the Fortran code. If we'd had standards for APL, perhaps they would have included something like, "Even though we KNOW you can do it and it's CLEAR as a BELL to you, do NOT put more than the equivalent of 100 Fortran statements on 1 line of APL." half a :-) Only experts can do this and they, of course, know everything and are most likely to want to be left alone. Standards are imposed on workers for other people, not the people doing the work. People with engineering backgrounds who look at some "standards" for programmers would be happy to deal with these rather than what they have to put up with. Most standards for programmers are trivial, e.g. stylistic. Programmers who can't follow these, and complain about impacts on creativity and productivity should be forced to comment the code of 50-60 programmers for the benefit of the nearest maintenance group. -- Mitch Che Pacific Bell 415-823-2454 --------------------------------------- "So what's the bird's-eye, lowdown disclaimer, disclaimer, too on this caper? Whatever that means." uucp:{ames,bellcore,sun}!pacbell!pbhyf!mche