Style wars
Brad Sherman
bks at ALFA.berkeley.edu
Thu Dec 29 08:59:07 AEST 1988
There are other stylistic questions apart from curly brace placement
and degree of indentation. (By the way, source code control systems may
thrash if cb and indent are used injudiciously %}.)
If there are 100 functions in the program are there 100 source files?
If not, what "rules" should be followed to chunk functions? (I used to
put the I/O routines in files with the functions which needed them; then
we started porting to odd ?NIX machines, VMS, and DOS-networks, now it seems
"better" to hide all those #ifdef's in I/O dependent files?!).
Does every source file have a declaration of *every* global
(perhaps via #include "global.h"), or should it be done on a need-to-know
basis at the top of the file? Or only in the body of the function which
references it?
Under what circumstances should sets of variables be glued together
into structures? Should functions know about variables which they don't
look at or modify?
If 10% of the functions need to know about a variable, should it
be made global? 50%? 90%?
How are we to document soon to be heavily used code (i.e. sure to be
modified after some experimentation)? If I find a nicely troff'ed document
from 10/86 describing your program, but I see that 10 sccs entries (i.e.
modification dates) have occurred since, should I read the document or
studiously avoid it?
" ... We might suggest that programmers adopt a systematic
stategy when they need to understand a program. While
reasonable, this is a totally impractical suggestion: a
systematic stategy can only really be adopted when a program
is smallish ... If a programmer attempted to use the
systematic stategy on a realistically large program, with
for example, 50,000 lines, the programmer would probalbly
never get to the enhancement."
Pinto & Soloway "Providing the Requisite Knowledge Via Software
Documentation," Proceedings of CHI, 1988. ACM, New York, p.257.
-Brad Sherman (bks at ALFA.Berkeley.Edu)
------------
"Hobgoblins have the consistency of small minds."
More information about the Comp.lang.c
mailing list