TITLE: make it right, then make it faster [ This picks up the tail end of a discussion on the disadvantages of a linear, sentinel-guarded search vs. the more trivial approach ] RESPONSE: ark@research.att.com (Andrew Koenig) Obviously this can still be made to work, but it becomes much less confidence-inspiring. RESPONSE: (James Kanze) I agree with Andy: the simpler the code, the better (until profiling shows it to be a performance bottleneck). RESPONSE: vandevod@cs.rpi.edu (David Vandevoorde) Doesn't this defeat the purpose of a library function to a certain extent? You develop your code with the lower-performance (arguably more reliable?) alternative and then (perhaps) find out it's not good enough and have to reinvent the wheel after all. Why not spend some time getting the not-so-simple code right and then not worry about it anymore (either way). RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 12 Oct 95 That might make sense if you have infinite resources and no schedule which must be met. (It doesn't matter how long it takes to finish or whether you ever finish.) More likely, your resources are finite and a product must be shipped before a "drop dead" date. Suppose you spend 40 hours honing a subroutine which now runs in half the time it used to take. If that subroutine consumed 0.1% of the execution time, you have managed to improve execution time by 0.05%. In the mean time, that was 40 hours you DIDN'T spend improving reliability or usability. It was also 40 hours you didn't spend on the subroutine that takes up 25% of the execution time. There is little point in spending time and effort improving a routine unless you know it is incorrect or inadequate in some way. I like to quote the adage, "Make it right; then make it faster." (I believe it is from Kernighan and Plauger's classic "Elements of Programming Style.")