denbeste@bgsuvax.UUCP (William C. DenBesten) (04/23/88)
In article <528@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: > I am interested in knowing how various C shops implement > company-wide style guidelines. It strikes me that it would be > madness to allow everybody to have their own style, as they can > be *so* different that it would be difficult for others with a > radically different style to maintain down the road. > ... I already have the style rules, I just don't know how > rigorously it should be mandated. From article <12120@santra.UUCP>, by news@santra.UUCP (news): > I would not hesitate to promote style rules > if I was convinced that they improve readability. The question, though, is > how do you enforce these rules, i.e., make sure that everyone is using > them. One solution is to write a program that does style checking according > to your rules and refuses to pass a program to the compiler if the style > used is significantly below the advocated standard. There is only one style that I would not have real troubles conforming to... my style. If forced to conform to a different style, my productivity goes down, and my frustration level goes up. The ideal solution, it seems to me, would be to have a beautifier that puts all the code into your company style, just before you freeze the code. Of course, if you don't trust the beautifier, you could write a short c program the would compare the before and after ignoring multiple white-space characters, to verify that it didn't change the source code. BTW: My style is identical to the style used in K&R, which I consider the closest thing to a standard for c programmers to follow. -- William C. DenBesten | denbeste@bgsu.edu Dept of Computer Science | denbeste%andy.bgsu.edu@relay.cs.net Bowling Green State University | Bowling Green, OH 43403-0214 | ...!cbosgd!osu-cis!bgsuvax!denbeste
news@santra.UUCP (news) (05/05/88)
In article <1962@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >>The ideal solution, it seems to me, would be to have a beautifier that >puts all the code into your company style, just before you freeze the >code. Of course, if you don't trust the beautifier, you could write a >short c program the would compare the before and after ignoring >multiple white-space characters, to verify that it didn't change the >source code. >... That sounds like a nice solution, except that there are certain styles that a beautifier cannot produce. For instance, how do you make it produce meaningful variable names? How do you make sure the program uses constants (defines) when appropriate? What do you do with too lengthy procedures? These are all style metrics that are important to asess the readability of a program. I agree that characteristics like indentation and blank lines can be taken care of by a beautifier. More comments appreciated. Nassim Bouteldja Helsinki University of Technology Dept. of Computer Science Finland E-mail : nbo@hutcs.UUCP
clb) (05/10/88)
In article <12567@santra.UUCP>, news@santra.UUCP (news) writes: > In article <1962@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: > >>The ideal solution, it seems to me, would be to have a beautifier that > >puts all the code into your company style, just before you freeze the > >code. Of course, if you don't trust the beautifier, you could write a > >... > That sounds like a nice solution, except that there are certain styles > that a beautifier cannot produce. For instance, how do you make it > produce meaningful variable names? How do you make sure the program uses > constants (defines) when appropriate? What do you do with too lengthy > procedures? The obvious solution to "how do ...": write a pre-processor to do exactly what you want. If editors can be written and compilers can be written, then this is just another application package. With "yacc" and a "lex", it's easy to get started. Of course, the names of variable must be predefined in some way, by management edict, committee resolve or something, but otherwise the problem seems do-able. If not, maybe the format being defined isn't realistic in the first place.
barmar@think.COM (Barry Margolin) (05/11/88)
In article <4043@killer.UUCP> loci@killer.UUCP (loci!clb) writes: >In article <12567@santra.UUCP>, news@santra.UUCP (news) writes: >> That sounds like a nice solution, except that there are certain styles >> that a beautifier cannot produce. For instance, how do you make it >> produce meaningful variable names? How do you make sure the program uses >> constants (defines) when appropriate? What do you do with too lengthy >> procedures? > The obvious solution to "how do ...": write a pre-processor > to do exactly what you want. If editors can be written and > compilers can be written, then this is just another application > package. With "yacc" and a "lex", it's easy to get started. I seriously doubt that we have anything close to the technology to do what you suggest. The point of the >> comment is that some of the important "style" rules have to do with understandability of programs. Do you really think that someone could write a lex/yacc program that would figure out how to rename single-character variable names to something that makes more sense to a human reader? These features are not just about static program format, but about how well the structure of the program reflects the problem being solved. It takes something with intelligence to do this. AI programs like the Programmer's Apprentice might be able to help in this regard, but they still rely on the programmer to do most of the work. But I think it would take a program smarter than we know how to build to determine whether the "1" in variable1 = variable1 + 1; should be replaced with a #define'd constant or not. It depends on just what the "1" represents in the context of the program; if we're just incrementing variable1 it should stay as it is (although perhaps a style improver might turn this into "variable1++;"), but if the "1" represents something more abstract it should be given a meaningful name. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
news@santra.UUCP (news) (05/12/88)
In article <4043@killer.UUCP> loci@killer.UUCP (loci!clb) writes: >In article <12567@santra.UUCP>, news@santra.UUCP (news) writes: >> In article <1962@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >> >>The ideal solution, it seems to me, would be to have a beautifier that >> >puts all the code into your company style, just before you freeze the >> >code. Of course, if you don't trust the beautifier, you could write a >> >... >> That sounds like a nice solution, except that there are certain styles >> that a beautifier cannot produce. For instance, how do you ... >> What do you do with too lengthy procedures? > > The obvious solution to "how do ...": write a pre-processor > to do exactly what you want. ... I can hardly imagine a pre-processor that can break-up my lengthy procedures into small manageable ones that carry out the original functionality that I wanted. It would have to understand what the program is doing, and that is not yet possible even using the current state-of-the-art of Artificial Intelligence. I reiterate my view of the issue: I am concerned about the effect of style on readability of a program. Some style characteristics, like identation, can be generated automatically, even differently each time according to a script that suits the reader. On the other hand, factors like the length of a procedure, can be checked automatically to be reported to the programmer in whom lies the responsibility to re-arrange his code in a more readable way.
pmjc@ur-tut (Pam Arnold) (05/16/88)
In article <12822@santra.UUCP> nbo@hutcs.UUCP (Nassim Bouteldja) writes: >In article <4043@killer.UUCP> loci@killer.UUCP (loci!clb) writes: >>In article <12567@santra.UUCP>, news@santra.UUCP (news) writes: >>> In article <1962@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >>> >>The ideal solution Two suggestions: wouldn't periodic code walk-throughs expose the people who are violating the local coding standards? If I knew that my code was going to be up on the wall every week, I would certainly make sure that it was up to snuff in terms of style (and hopefully substance as well). This one may beg the question, but if any shop is REALLY SERIOUS about this sort of problem, why not switch to a more modern language, especially one that is more tailored to the requirements of software engineering? For example Modula-2 and Ada (no flames, just add your own to the list).
peter@athena.mit.edu (Peter J Desnoyers) (05/16/88)
It has been suggested that the way to create uniform coding standards in a group is to use a beautifier that converts any style of code into the officially sanctioned style. It has been pointed out that this is not possible, in the general case, given the current state of the art. I would suggest that it may not be a good idea, either. One of the benefits of a reasonable set of code standards is that one person can pick up another's code and read it or modify it with less effort than if a multitude of styles are used. (Don't you love modifying code that is indented differently from the editor defaults you use? I usually end up reformatting the entire file.) Anyway, for some suggestions gleaned from experience with a few groups that had coding standards - Global names - functions and variables - are important. There should at least be a structure for these names, so that the name identifies the module. A rule to distinguish function and variable types - e.g. booleans are named foo_p - might be useful, and might not. You might want to have all _really_ global names approved by one person. File and function headers should be standardized and should contain enough information. Arguments, description, side effects, and modification history are good starters. For protocol or compiler stuff, references (to defining documents) are useful as well. Someone should create templates for these things, and maybe standard editing macros like box-region. These are more management - rather than technical - issues, and should probably be discussed in the beginning when you set up source code control and release procedures, and other things like that. I don't like the idea of checking style by machine - I think it should be checked by a human during code review. Of course, if the program is small - say less than 30 files - you can probably ignore most of these issues. Peter Desnoyers peter@athena.mit.edu