Oppolzer - Informatik / Blog


Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

ASSEMBLER-L - Versteckte Fehler, verschleiert durch irreführende Kommentare

Subject:

Re: code comments

From:

Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>

Reply-To:

IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU>

Date:

2012.02.10 22:35:04


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
good.

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.

Kind regards

Bernd



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.
>
> J.G.
>

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie