This looks like the start of a good list and it probably deserves it's own thread, and unless these items are subsumed in more APIs or available in some framework (I've seen a couple kicked around) they may deserve their own page in the help section. I can think of a couple other items we seem to be taking care of:

1. Make sure the symbols in your universe are tradable
   
2. Have a strategy for handling pending orders
   
3. Have guards to ensure you are not over-levered

Anything else?

Paul,

I agree; I could really benefit from a list of best practices for writing algos. I'll add another one:

1. Remove price and volume objects that have incomplete data (NaN). I have seen this done several ways, but it would be nice to see the best practice methods to accomplish this.

2. Always add a decimal point to variables that need floating point calculations performed. For example, don't use "1", instead use "1.0" (Someone smarter than me can explain how integer operations are different than floating point. All I know is that this has messed me up multiple times. I think that the default behavior has changed in Python 3.x, but the Q IDE is still using Python 2.x.)

Paul,

I agree that we need a separate thread for this. I could really benefit from a list of best practices for writing algos. I'll add another few:

1. Remove price and volume objects that have incomplete data (NaN). I have seen this done several ways, but it would be nice to see the best practice methods to accomplish this.

2. Always add a decimal point to variables that need floating point calculations performed. For example, don't use "1", instead use "1.0" (Someone smarter than me can explain how integer operations are different than floating point. All I know is that this has messed me up multiple times. I think that the default behavior has changed in Python 3.x, but the Q IDE is still using Python 2.x.)

What comes to my mind are:

1. If algo is using fetcher can there be any guard against breakdown of server hosting .csv file.
   
2. If your universe is dynamically created. Is there a mechanism in your algo to address any open positions of equities removed from universe at later date. .

I think that Quantopian needs a bulletin board which supports "sticky" posts, which can only be initiated and maintained by a moderator. Then you could maintain a few helpful checklists.

The ones I think could be really useful include:
1) Best practices for live trading and/or robust algorithms
2) Gotchas in moving code between the IDE and the research environment
3) Useful commonly used routines/code snippets

others?

If "sticky" posts are not on, I'd at least suggest clearly identified threads for each checklist, maintained exclusively be Quantopian, otherwise they will quickly become bogged down with other stuff.

@Alisa, your list is great. Would you be prepared to share some coding ideas to implement them :)

bulletin board which supports "sticky" posts,
+1

1. Wherever possible, try to avoid parameters, and especially avoid optimizing them to an entire backtest of data. Either pick them based on some fundamental rationale and leave them alone, or have the algo calibrate them on a walk-forward basis.
   
2. If you are managing stops in a stateful way (ie: making sure they only move closer to the position), do not save the stop price in context - that will break if the asset has a stock split. Instead, recalculate yesterday's stop using yesterday's price from history().

I'll add more if I think of them.