[ILUG] Re: C++ Coding Standards

[Brian Foster]

  | Date: Mon, 2 Apr 2007 10:48:23 +0100
  | From: Sonic <sonic at dreadserver.com>
  | 
  | On Fri, 30 Mar 2007 23:10:51 +0200, Brian Foster <blf at blf.utvinternet.ie> wrote:
  | >[ ... ]
  | >  apologies if I'm coming across as a bit strident,
  | >  but besides just returning from the pub  ;-)  the
  | >  tendency to conflate the conformance of source code
  | >  to some stone tablet with the code's functionality
  | >  and quality is one of my "Hot Buttons".
  | 
  | That's cool Brian,
  | 
  | Our group is new and I was just looking to make things
  | easier from the get-go.  We've never before seen each
  | other's code and there will (hopefully) be others from out
  | there in Internet land who contribute.  I would like if they
  | used the conventions we're used to if they contribute.  This
  | is why I'd like something concrete to link to.  I do
  | think this is important though but your experience may
  | differ.  I'm just trying to follow a set of principals I
  | think make sense and will make life easier.

 I understand.  but please allow me to argue the 3-rule
 approach still works:  the main issue (in yer case)
 seems to be "existing code".  it sounds like you don't
 have any.  in which case, Yes, find a stone table.
 treat it as yer existing code (i.e., the style that is
 to be copied).  the three rules now kick in:
      3. follow the existing code;
 else 2. it's Ok if the coders and reviewers _agree_ it's Ok;
 and  1. all reasonable exceptions are allowed.

 also, notice this is evolutionary  — it adapts to yer
 experiences (is not cast in concrete) — since agreed
 deviation to existing code establish an accepted new
 body of existing code.  so, over time, it works itself
 into a form everyone can live with.  (something stone
 tablets tend not to do (in my experience).)

 and to be absolutely clear on one thing:  I'm not
 saying (and have tried to never imply) style doesn't
 matter.  of course it does!  however, neither style
 _conformance_ nor _non_conformance_ is the same as
 _quality_.  doing both — conforming unless there
 is a good reason not to — helps quality (especially,
 perhaps, when people agree quality, not what a stone
 table says, is more important).

 FLOSS has an advantage here (IM(H?)O):  many eyeballs
 and nominally open discussion; i.e., the code really
 is reviewed.  but it also means you may get pedants
 who insist there is a problem because of some obscure
 clause in the stone table.  but again, this is where
 the 3-rules approach helps:  a pedant raises an issue,
 someone(s) else (eventually, hopefully) looks into it,
 and then either there's a rational discussion and
 agreement, or else pedant's point is simply accepted
 and the code changed.

cheers!
	-blf-

  | Cheers,
  |  Sonic
-- 
Experienced (>25 yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com