[comp.lang.c] Efficient coding considered har

mcdonald@uxe.cso.uiuc.edu (11/04/88)

I've observed a lot of users using a lot of programs over a long
time. I note that the order of the following list has changed over
the ages. But today I really believe it to be true.
         User's Program Priority List (1 is highest priority)

1.   Cost is <= amount of money purchaser has at hand.

2.   Utility. The program must do what the user need it for. It must have
     ALL necessary features. For example, if the user's name is 
     Co^te', a word processor is useless if it can't get the accents
     over the letters. If a word processor can't produce integral
     signs it is useless to me. If a spreadsheet can't produce pound
     signs (which this medium can't!), it is useless in England.

3.   Look and feel. It should look nice and be easy to use. For a
     large and growing segment of the world, this means it should
     work like a Macintosh. Lacking that, it should be full-screen,
     and use all the functionality of the computer it runs on.
     For example, word processors should properly display imported
     graphics. Fonts should appear on the screen as they do on paper.
     Menus and commands should be used INTELLIGENTLY, at the whim
     of the user. There should be more flexibility here than is usually
     the case - a Mac failing, slowly being remedied.

4.   Speed. Speed. Speed. More speed.

5.   Small memory usage.

6.   Bug-free. Note that this is number six. Users will tolerate small
     bugs if a program is otherwise suitable. But they will mercilessly
     flame the seller. If that seller give an essentially free update
     that fixes the bugs, users will not actually blacklist the seller.

7.   Portability of program. Users would like to be able to use the
     same program on different computers.

8.   Cost. If item #1 is met OK, actual cost doesn't seem to be
     very important.
_________________________________________________________________________
     User's don't care AT ALL about items below this line. This implies
     that they matter only as they impact things above the line.

A.   Portable source code. Users don't read source code. But they do
     do know what "vaporware" is.  

B.   Easily maintainable source code. Users don't read source code.

C.   Language program is written in, whether it is "structured" or
     not, whether it is "object oriented" or not. Users don't read
     source code.

Of course, if the user and programmer are the same, or closely related,
the order may change.

Comments and flames are welcome.

Doug McDonald (mcdonald@uiucuxe)

rgh@inmet (11/13/88)

>another teacher here loves ANSI C, and every 'enhancement' he mentions
>smacks me of being Pascalish in orientation.  For example, the
>declaration of variables within the function parentheses will
>provide the 'protection' that Pascal lovers want only if the
>compiler can compile both the caller and callee at the same time.
>Or the linker must be more sophisticated, using information that
>is generated by the compiler.  How will it be handled folks?
>Either way we lose.  If the compiler does it, there goes our
>modular strategy of putting related functions in seperate files
>from the functions that use them.  But then we could always
>#include C code files, which is exactly what one of the afore-
>mentioned teachers required of beginning C students!  But what
>if I want to package a set of functions for users of equipment
>I manufacture to connect to the computer and I don't want them
>to have the source?  Then the linker will have to do it.  Will
>that cost more for the compiler and linker?

Apparently you've not been informed that function declarations can
use the prototype notation [i.e., declaring argument types as
part of the function header] as well as function definitions.
This addresses all your concerns:  you put a prototype function
declaration in an include file, and include that in all the modules
that call that function, and in the module that defines the function.
The linker doesn't have to do anything special.  You market your
function package as an include file that declares the functions,
along with the object modules that define the functions.
Fairly standard practice these days is to write a .h file declaring
the types, macros, functions that form the external interface of
the corresponding .c file.

There are potential efficiency gains in this prototype business
which should interest you.  In the absence of prototypes, integral
arguments have to be at least int-size, and floating arguments have
to be at least double-size.  That is, an actual argument of type
float is converted to double in the calling sequence.  If the
caller and callee can agree, via prototypes, that the argument
really is a float, then the conversion can be omitted.

More fundamentally, C implementors have had to assume that any function
call might be to a function that takes a variable number of arguments
(such as printf).  This constrains calling sequence design in
various ways.  For instance, several machines have a Return instruction
with a operand specifying how much data to pop off the stack.  You
can't use this instruction unless you know how big the argument
list is, which in classical C you don't.  So generally the argument
list gets popped off the stack at the call site, certainly more
expensive in space and often in time.
Now part of the prototype syntax is specifying functions (like sprintf)
that take optional trailing arguments.  All other functions can
be assumed to take a fixed argument list.  Thus an implementor 
could choose to use that Return-popping-n instruction in most cases.
Passing arguments in registers also becomes a more attractive implementation,
for similar reasons.

Randy Hudson  rgh@inmet.inmet.com   uunet!inmet!rgh

joe@modcomp.UUCP (11/21/88)

Steve Summit (scs@adam.pika.mit.edu) writes [slightly edited]:

> There is an abominable quantity of horrible code in existence today, and
> egregious amounts of time are wasted trying to fix neverending bugs, trying
> to add seemingly reasonable features which the "architecture" inexplicably
> prohibits, and finally abandoning the whole mess and rewriting it from
> scratch.

I agree completely.

> I will be vehemently disagreed with, but I submit that most of this
> unmaintainable code arises out of misplaced concerns for "efficiency."

Some of it, yes, is produced by otherwise good programmers with misguided
notions of what is important.  However, my experience has been that most bad
code comes from bad programmers.  These fellows don't try to put "efficiency",
or anything else, into their code.

> It is true that there are a lot of miseducated programmers out there, but
> their miseducation often derives from teachers and textbook authors who
> constantly harp on efficiency without teaching moderation, and from the
> badly-written code by which they are surrounded and which they (the
> students) inevitably emulate and go on to perpetuate.

I'm not sure if the swarms of bad programmers are due to miseducation.
Certainly, my teachers didn't harp on efficiency issues; there just wasn't
enough classroom hours to do that and also get the basic concepts across.
Rather, a lack of excitement for the field, a mismatch of skills, perhaps
due to the selection of a career based on paycheck rather than interest, may
be the more important factors.

Of course, it doesn't help that the problem of writing truly maintainable,
flexible code is one of the most challenging and creative things available
to the working programmer.  I suspect that none but the best of us will ever
be very good at it, at least, not until the "general principle of creativity"
has been discovered and reduced to a rule of thumb (:->).

> When assigning priorities, though, I would rather have people learn clarity
> and good style first, and efficiency as the need arises.  (Among other
> things, the marketplace imperatives of which we are endlessly reminded will
> ensure that efficiency will not be neglected; while there are, sadly, not as
> many incentives for writing clearly.) The industry is not plagued by slow
> programs (compilers being tuned for the benchmarks to the contrary
> notwithstanding).  The industry is plagued by software that is over
> schedule, over budget, buggy, and unmaintainable.

Right on the mark.  No one could have said it better.

Joe Korty
uunet!modcomp!joe