on standards and design

This is just a part of a long series of forthcoming mails most likely.


m_ variables are reserved for object private/protected/public data.  Not 
  private data to methods (functions).  Any instances of local variables 
being named with the m_ prefix should be fixed as you see them.

Any structures or variables only used in a single object should be 
private data to that object.

If object has equivilant objects already around, data variables that 
hold the same type of data found in the other object should be named the 
same as they are in the other object. for instance, if i have a pointer 
in object A holding buffer data and I'm working on a new object B. I 
should name my pointer holding buffer data the same as it's named in 
Object A.

The first and last here are for making reading zinf code easier and more 
clear to people who haven't had the time to read just about every line 
of code to zinf.  The second can have multiple reasons to be done, code 
cleanliness, variable integrity, thread-safeness. etc etc.

The second and last aren't my inventions, they're guidelines that were 
made initially but not strictly enforced in the code.  Strict 
enforcement of guidelines is necessary in our situation.  We have to 
mold zinf into a stable extensible player and this cant be done with lax 
design guidelines to public interfaces such as plugins/pipeline stuff.



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en