🚀 go-pugleaf

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