The code must be properly formatted, nice to read. You must have testcases.
- Always start with simple even dumb code. (e.g. as is written in the spec you write it down no matter how stupid or inefficient)
- Trade simplicity/clarity for speed, if the gain is big. (e.g. move from the letter-of-the-spec-matching code to something actually faster, sometimes also clarity and simplicity gain from it)
- Trade space for speed, if the gain is big enough. (e.g. a lookup table usually is a nice solution, sometimes for a different problem)
- Trade precision for speed if you must, always leave a codepath that isn’t imprecise.
- Never trade portability, but you might trade slower generic code for faster specialized code for all the platform implementing it. (e.g. implement in asm a function that was inlined before, the plain C code would be slower since you have a call overhead while the asm-optimized version would be 16-fold faster than C)
As Kostya pointed, sometimes you start with a binary specification so point 1 is moot.
I find the first item hilarious since I know the specs I implement decoders after (hint: they are often binary), so there’s neither simplicity nor clarity to start with.
Also diego-english-nit: “trades” means “kinds of occupation”, you probably meant “trade-offs”.
trade (noun), meaning 5 =)
http://oxforddictionaries.com/definition/english/trade has only 4 meanings 😛
And I still believe you are talking not about mere acts of swapping X for Y but rather how much of X you can/should sacrifice for achieving Y, i.e. trade-off.