Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!osu-cis!dsacg1!dsacg3!vfm6066
From: vfm6066@dsacg3.UUCP (John A. Ebersold)
Newsgroups: comp.lang.c
Subject: Re: Efficient coding considered harmful?
Message-ID: <1163@dsacg3.UUCP>
Date: 7 Nov 88 18:16:40 GMT
References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <8630@smoke.ARPA> <1704@dataio.Data-IO.COM> <119@twwells.uucp> <7700@bloom-beacon.MIT.EDU> <137@twwells.uucp> <8819@smoke.BRL.MIL> <190@celerity.UUCP>
Reply-To: vfm6066@dsacg3.UUCP (John A. Ebersold)
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 32


I have been following this for some time.

My two cents...

Balance all coding "tricks" against the need to produce readable and thus
maintainable code.  

Get the code working properly first, make sure it can be read and understood
by programmers less talented than yourself.

Comment liberally, (the l-word and oh nooo the c-word), however do not
re-state the obvious, e.g,

#define EOF 0

/*
** Read until end of file  (silly comment)
*/
while (fread != EOF)

(Don't laugh, I've seen it done).

Misleading comments are worse than no comments at all.  If your algorithm
requires five times as many lines of as the code - so be it.  You may be
immersed in it now, but try and remember what is going on six months from
now - pity on the poor maintainer.

The most important comments are those that give the BIG PICTURE, followed by
those that show how the parts fit into the whole.

Lastly, if it is too slow, profile it and fix the slow parts in a readable
manner.   Humbley (is that a word?).