Yes, that's always good advice. But there are even more important things about crap code: often it will cripple your ability to debug/maintain/enhance your system - and a system that doesn't grow into new things is a system that is dead; especially when "actually working" is one of those new things.

There's a nice example of crap code here. I haven't a clue whether it will cripple performance or not. I don't even know whether the crappiness is just layout or whether it's a blockheaded choice of join structure, But I know for certain that it already has crippled people's ability to understand what it does and why it doesn't work. The OP can't understand it (that's what he wants help with). Grant didn't understand it. I didn't understand it. So I wrote code to analyse one aspect of it (which is how I learnt that Grant's comment was wrong, hence that he didn't understand it). Everyone who has commented thinks it's crap code. I think writing code like that is a crime, an assault against all standard of decent code. But I'm not actually sure it's going to cause performance problems if it can ever be got to work.