🚀 go-pugleaf

tangent@cyberport.com (Warren Young) writes:
>These samples _are_ pretty wordy, no doubt.  As to the fact that both
>can be adequately replaced with sprintf() calls can probably be
>explained as: 1. ignorance; or 2. efficiency by writing a special-
>purpose function instead of going through a general-purpose function.
>How valid the latter argument is depends on the application, of
>course.

But the code is not efficient!  A binary->hexadecimal routine can be written
in less space than either example, then used in both.  The examples ALREADY
call a function, but they call the wrong one, and then waste a lot of time
patching up the result.  The author is supposed to be an *expert*.

>>Line 1:  two superfluous pairs of parentheses, could be
>>    ltoa(lBufIndex*16, buf, 16);

>I must make a specific comment here, though: While the original was
>unquestionably paren-happy, don't discount code where extra parens
>really _do_ add to clarity.

I don't discount it, any more than I discount the importance of white
space.  Adding too much of either all the time, however, helps no-one.
Again, the point is that this guy is *supposed* to be an expert.

>However, I do appreciate C's compactness of expression on occasion.

Let me say it once again:  compactness of EXPRESSIONS is not at all the
same as compactness of PROGRAMS.  A programmer who writes 20 ten-character
lines has written a less compact PROGRAM than a programmer who writes 10
twenty-character lines, even though every EXPRESSION in the first program
is more compact than every expression in the second.  I think that was my
main point, really.

>String parsing routines are very often this way.  (Isn't it ironic
>that the code snippets you showed _were_ string parsing routines?)

It would be, except that they were actually string _generation_ code
that wouldn't have been doing _any_ parsing if it had been done right.

-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.