|
Re: What is the Worst Code You've Ever Seen?
|
Posted: Jan 8, 2007 10:59 AM
|
|
> > > > If code unnecessarily opens and closes extra database > > connections in the same loop within 3 lines of each > other, > > that's bad. > > > > If code implements a sorting routine on an array of > values > > returned from a database query such that the sorting > takes > > too long to complete on less than 1,000 records (On the > > web version the page would time out. The desktop > version > > took over a minute to sort ~1000 records) when you > could > > have used 'ORDER BY' and returned your data already > sorted > > in a fraction of a second for many, many thousands of > > records, that's bad. > > > > If the scenarios that you site actually meet the > requirements of the project (which I doubt since > reasonable efficiency is usually a requirement) than I > disagree. Non-optimal applications that fully meet their > requirements don't really bother me in a business sense. >
> Faster is usually better (except perhaps in some real-time > scenarios), but there's always a trade-off between > optimization and the costs of performing it. Obviously you > sited extreme examples, but the trade-off is always there.
I've only personally seen one spec that ever had any kind of efficiency explicitly stated as a requirement. So, according to you, since there are no default requirements, this shouldn't be a problem.
You say that the examples are extreme. Extreme or not, I had to fix them. I agree in principle but these problems seem so common. I've never seen any developer defend his work successfully by saying something like "It may run like a 3 legged dog, but it meets the specified requirements." I've seen them try, but they fail miserably. Reasonable efficiency is, in my experience, always a default requirement. In my career if I had to pick one type of problem I fixed the most, it would be off by one errors. A very close second would be "make it perform in a 'reasonable' manner."
There are also two other default requirements in my experience. Failing gracefully and acting in a manner users expect. These two aspects are rarely, if ever, explicitly stated in the projects I've worked on but you'll get hell to pay if you don't do either one of those.
|
|