kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) (12/14/90)
The following is a summary of the responses to my recent posting: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. It's fine to adopt a coding >standard (that's exactly what we're looking into) but without automated tools >for verifying compliance it becomes unreasonable to enforce the standard. >While I agree that code reading has numerous benefits and should be used >extensively, I don't think that reading for style compliance is very >profitable. > >Are there any such tools available publically? We have one tool in-house >but it is outdated and inflexible. What tools are people using to verify >compliance? Thanks for all the replies. We are currently looking at the Abraxas and Mindcraft offerings mentioned by Bill Hahn, but have made no determinations as to how we will proceed. Kyle. ----------------------------------------------- cox@stpstn.UUCP (Brad Cox) writes: Why bother with compliance checking tools. Wouldn't the same effort be spent more productively on a pretty-printer that reformat source to whatever formatting standard you prefer, and let people write as they wish? <I'm referring only to whitespace placement here, not to substantive issues of variable naming, etc, etc.> ----------------------------------------------- stank@anvil.WV.TEK.COM (Stan Kalinowski) writes: Doing the programming style checking in code reviews actually works fairly well. With most people, habit quickly takes over and then the checking for style can be lessened. It is very important to properly document the standards and communicate it to the newcomers to the group. I have seen groups that tried to inforce style guidelines with tools, it tends to fail. Usually the reason for the failure is that the group has not come to a concensus on what the style should be, communication breaks down, and the majority tries to force the dissenters into the chosen style through the use of tools that prohibit exceptions. This is not good for a project. Some sort of compromise must be reached, it is usually best in these situations to bring in a disinterested third party to set the standard, whereupon all parties envolved agree to abide by the result. I have heard stories of engineers writing tools to translate back and forth between styles, just so they can code in their own style and still comply with guidelines set by a project. This strikes me as a ridiculous waste of time and increases the opportunity to cause bugs. Personally, if I were to come into a group and I found the engineers quibbling over style guidelines, I would probably quit. Such quibbling is usually a sign of deep seated interpersonal problems within the group, or possibly irrationality on the part of one or more engineers. One project I worked on actually provided emacs macros that, when used with electric C mode, actually helped the user comply with the coding standard. The idea behind this was to make compliance easy and non-compliance more difficult, but not impossible. Remember, there are always exceptions to any rule, and people tend to exibit better judgement than machines. If an inflexible enforcement tool is in place, it may force engineers into awkward coding just to placate the tools. ----------------------------------------------- cml@tove.cs.umd.edu (Christopher Lott) writes: Gosh, a tool for verifying compliance to a style guide? I think a code review may be the "tool" (certainly the technology) that will accomplish this best. I see a style guide as a way for an organization to produce code that is equally legible to all, and will hopefully be more easily maintained within that environment. Hopefully the style will be accepted and used cheerfully by all, so that all will learn both to read AND write code in the chosen style. On the surface, you can consider purely formatting aspects, but at deeper levels (such as, for example, interfaces for all central lib routines) some style guidance may enhance the coherence of a software system - making it look like it was designed and built by a single mind. chris... ----------------------------------------------- donm@margot.Eng.Sun.COM (Don Miller) writes: The response to the original poster's request for an automated style compliance verification tool reinforces my belief that this is another culturally dependent software development technique. To "enforce" anything but a quantifiable, documented, agreed upon standard with "permission" to evolve is, in my experience, fruitless. Even if the above qualifiers apply to an organization's proposed coding standard, the beneficial impact will, to a great extent, depend on the cultural receptivity to such a "constraint". Beyond the theory, I also have a practical contribution to the original post. If you indeed have a "pretty printer" that can output code in the desired standard format, you have your automated style verifier. Just run the code in question through the pretty printer and compare the resulting code with the original. As long as the "pretty printer" isn't doing other non-standard related modifications, the deviation from the standard will be the result. In UNIX land (SunOS of course :-): indent [options] source_file.c ; diff source_file.c source_file.c.BAK ; {mv source_file.c.BAK source_file.c} where [options] reflect the standard programming style, to the greatest extent possible. The mv is necessary since indent replaces the original source file with the "standardized" equivalent. Not a perfect solution, but relatively cheap. Previous comments referencing the questionable value of maintaining tools which must do parsing independent of the compiler apply. ----------------------------------------------- mikec@praxis.co.uk (Michael Chace) writes: >>>>> Regarding Re: Automated tools for verifying C style compliance?; cox@stpstn.UUCP (Brad Cox) adds: Brad> In article <4990@tekfdi.FDI.TEK.COM> kyleb@tekfdi.FDI.TEK.COM (Kyle Bernard) writes: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. Brad> Why bother with compliance checking tools. Wouldn't the same effort be Brad> spent more productively on a pretty-printer that reformat source to whatever Brad> formatting standard you prefer, and let people write as they wish? Why not do better from scratch by using a decent editor (ie emacs) that has an adequate mode for editing C source files ? Mike ----------------------------------------------- zvr@ntua.gr (Alexios Zavras) writes: In article <3086@exodus.Eng.Sun.COM>, donm@margot.Eng.Sun.COM (Don Miller) writes: > In UNIX land (SunOS of course :-): > indent [options] source_file.c ; diff source_file.c source_file.c.BAK ; > {mv source_file.c.BAK source_file.c} Assuming that indent(1) works, of course. It didn't treat files with lots of #ifdef's very nively, last time I checked... (Of course, really portable programs don't use #ifdef's anyway :-) Anybody ready for starting a "my indent options are better than yours" argument ? -- zvr -- ----------------------------------------------- Bill Hahn <bhahn@bogus.sw.stratus.COM> writes: Abraxas Software has a C style compliance checking tool called CODECHECK. (503)-244-5253. FAX: (503)-244-8375. Mindcraft, Inc. has a "C Portability Verifier". (800)-LE POSIX, FAX: (415)-323-0854. Caveat: I don't have enough experience with either of these products to offer an opinion about their worth. If you hear of any others, could you please send me EMAIL or post a summary to comp.software-eng? Thanks. -- Bill Hahn bhahn@bogus.sw.stratus.com Stratus Computers "I would no more lie to my government than my Marlboro, MA, USA government would lie to me." - graffito in Maryland --------- These are my opinions and not necessarily those of Stratus.------ ----------------------------------------------- aro@cs.aber.ac.uk writes: >I've recently read over the C style guidelines from giza.cis.ohio-state.edu >(128.146.8.61) and it seems their usefulness is very limited due to the lack >of automated compliance verficiation tools. It's fine to adopt a coding >standard (that's exactly what we're looking into) but without automated tools >for verifying compliance it becomes unreasonable to enforce the standard. >While I agree that code reading has numerous benefits and should be used >extensively, I don't think that reading for style compliance is very >profitable. I suspect that the lack of automated compliance tools is that while people claim to like coding standards, in fact everyone seems to want to invent their own. >Are there any such tools available publically? We have one tool in-house >but it is outdated and inflexible. What tools are people using to verify >compliance? In many organisations, formal code inspections take place which are a good opportunity for checking compliance with coding standards. But it doesn't answer your question, I'm afraid. Andy Ormsby, aro@cs.aber.ac.uk ----------------------------------------------- Ghassan Abbas <abbas@beirut.sparc.COM> writes: > I've recently read over the C style guidelines from giza.cis.ohio-state.edu > (128.146.8.61) and it seems their usefulness is very limited due to the lack > of automated compliance verficiation tools. It's fine to adopt a coding > standard (that's exactly what we're looking into) but without automated tools > for verifying compliance it becomes unreasonable to enforce the standard. > While I agree that code reading has numerous benefits and should be used > extensively, I don't think that reading for style compliance is very > profitable. There is already one such tool: SACT (SPARC APPLICATION COMPLIANCE TEST) which is based on the ASV (a tool from AT&T which check your C program to see if it comply with a certain standard). the ASV comes with SVIDI,SVIDI2,POSIX,XPG3,FIPS, SACT come with all these standard in addition to the SCD1.0 (SPARC Compliance Definition). The ASV of AT&T comes with a tool (avbuild) which let you define your own standard in a form of database read by AV (application verifier) which use your database to check the application. It also, use it is own version of lint. Ghassan Abbas, SPARC International,Inc. Menlo Park, CA ----------------------------------------------- -- uucp: tektronix!tekfdi!honda!kyleb US Mail: Kyle Bernard, Microwave and RF Instruments, Tektronix, Inc. Box 500 MS 58-072, Beaverton OR 97077 Phone: 503-627-3522