Posted 04 June 2013 - 09:30 AM
I'm with NooM here, try and keep classes as self-contained as possible. Avoid scattering bits and pieces as statics in the main class. Gather and isolate things that belong together. In my opinon, the more globals, the worse the code in terms of clarity, change management, maintainance, porting, scalability, generalizantion, scalability, etc.
Be aware of the limited amount of system resources, primarily RAM and processing power (your code is being interpreted at run time, there's no JIT here). Create late and destroy early. Be clever and figure out more efficient ways of doing calculations etc than you perhaps normally would. Optimize, use hash tables. Keep it short, lean and mean.
Whenever possible, use event driven constructs (interrupts) rather than polling. Avoid tight loops as much as possible. Use multithreading concepts like producer/consumer relations between threads employing sempahores and mutexes. The scheduler does a really excellent job, sometimes almost magical. If you must do tight stuff, remember to yield once in a while in favor of other threads.
Other than that, at least I don't take any particular explicit actions for memory management. In general, the GC normally does a better job when left in peace.
Personally, I don't care much for IDispose. I mean, if you for example instanciate a driver class for an LCD, a switch or something like that - would you dispose of it run time? I know I wouldn't. Naturally, transient objects should be disposed of early, don't allow stuff to "build up" over time.
EDIT: Of course, don't apply all of the above per sé but selectively when necessary, sensible and justified.
