I believe like J. that written coding standards - without a respected and
accepted person who enforces these standards and is capable (and has time) to
talk, teach and explain to the coders why the standards are useful etc. - do no
I once met a guy who had such a job. He has now retired. He was a kind of "code
inspector" in the company, some 100 developers. All PL/1 programs had to pass
his desk; he also supported the coders when there were errors or programming
problems. He was very esteemed and respected, although he often did not accept
the programs in the first place.
But I have the impression that there are not much persons like that in today's
companies, and if so, such jobs would be considered non-productive by management
and probably eliminated.
Am 10.02.2012 20:50, schrieb J.G.:
> D.J. wrote
> <begin snippet>
> I disagree with J.G.'s assertion that "coding police" do more
> harm than good - we have strict coding standards and a code quality
> inspector who has probably the worst job in the department, but makes
> sure that all code conforms.
> </end snippet>
> He is and should be entirely free to do so. Controversy is useful.
> My own experience has been that
> 1) coding standards always go too far, regulating minutŠ;
> 2) coding standard are often retrograde; they too often mummify
> obsolescent notions;
> 3) coding standards, developed usually to give guidance to programmers
> of 'junior understanding', prevent others from using technology they
> do understand;
> 4) coding standards are often vague, like the injunction found in many
> COBOL shops' programming standards to avoid 'negative logic';
> 5) coding standards enshrine dubious practices;
> 4) coding standards deflect attention from apprenticeship and
> mentoring schemes useful for teaching people how to write better code,
> diverting it to enforcement activities;
> 5) coding standards too often embody an ideology--strong typing,
> say--that is dubious;
> etc., etc.
> Functional standards--naming conventions, calling-sequence
> conventions, and the like--are of course useful, even indispensable.
> Justice Holmes made my case long ago when he said, "Rules are for
> clerks . . . "
> I regularly look at clients' programming-standards manuals; I have yet
> to see one that was not uninformed and small-minded; and most are
> preoccupied with some notion of maintainability that confounds simple
> and simplistic. More often than not they are dead letters too, and
> this is as well.