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.

Bookmark the permalink.

3 Responses to Trades

  1. Kostya says:

    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”.

  2. Kostya says: has only 4 meanings :-P

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>