Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP Path: utzoo!watmath!clyde!floyd!vax135!houxz!houxm!ihnp4!zehntel!hplabs!hao!cires!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.unix-wizards Subject: Re: _print/_doprnt; curses on sys III Message-ID: <561@opus.UUCP> Date: Wed, 27-Jun-84 02:33:48 EDT Article-I.D.: opus.561 Posted: Wed Jun 27 02:33:48 1984 Date-Received: Fri, 22-Jun-84 07:33:31 EDT References: <1101@wateng.UUCP> <4561@utcsrgv.UUCP> Organization: NBI, Boulder Lines: 26 Dave Sherman is defending his use of the internal functions _print/_doprint in his code: >1. Good documentation will avoid the portability problems. I am clearly >documenting in my code exactly what the v7-stdio dependency is. How many times have I overheard someone discussing a disastrous bug when some gadfly comes up, cackles "So document it and call it a feature!" and goes laughing off into the distance. Documentation doesn't avoid the portability problems, it only points out where they are. Well-documented bad practice is still bad practice. >2. "two lines of code is a small price to pay..."? Not when two lines >would have to be used for every printf in a source file which has a >lot of printfs, escpecially during the development phase. So use a procedure or a macro to encapsulate the two lines. That should be obvious - performance, to the tune of an extra procedure call or so, is hardly an issue when printf is at the business end. I think (hope) that the effect of this discussion will be to convince Dave that what he's doing is "bad practice" such as the collective conscience of the net might define it. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!