Claudio Lassala
Hi Joe,
Here's a list with rules that I wrote here at the company:
- Rules to check for XML comments (we know that the compiler can enforce that public members have XML comments, even though it doesn't check whether the XML comments actually have something typed in it... we wanted to make sure developers aren't just getting away with empty XML comments, and we also want developer to put comments on every type and type's member, no matter what the visibility is):
- All type members must have xml comments
- All types must have xml comments
- Assembly libraries need to have valid XML docs (this one I borrowed from an MSDN article)
- Rules for naming conventions:
- Variables should have meaningful names: we don't like variables named like "i" or "j" for counters in for-loops, so I wrote this rule that asks the developer to give variables some more meaningful names.
- Rules specific to users of our framework:
- Business Entities must not have public constructors (those objects are meant to be instantiated through Factory methods)
- Business Objects must not have public constructors (same reason as above)
- Do not create DB Command objects directly (developers shouldn't do data access directly using ado.net stuff... they should always use our biz objs or DAL instead).
- Do not create DB connection objects directly (same reason as above)
- Local variables should always use generic data interfaces (this is to make sure developers don't declare variables of type SqlCommand or OracleCommand. Instead, they should declare it as IDbCommand or IDbConnection, and use our framework factory methods that give them the appropriate concrete types)
- Only Milos (our framework) Configuration System Should be used (we wrote our own Configuration system, which wraps up the standard .NET one, but adds more functionality, so we don't developers using the native .NET one).
- Public methods on business objects must only return serializable types (since the biz obj may sit on a different server, we need to make sure the objects it returns can be serialized).
- Business Objects must follow naming convention (any class inheriting from our BusinessObject, BusinessEntity, BusinessRule, BusinessCollection, etc., should follow our naming conventions for it)
- Avoid enabling "allow save with violations" on business objects (this is a recommendation to the developer)
- Avoid instantiating Business Objects in Business Entities (we already have a special method on the entity to get to the biz obj).
- Command parameters must be added using milos (we don't want developer adding parameters to DbCommand objects directly, we want them to use a method in our framework instead. That way we can handle things like the fact that only the SqlDbCommand.Parameters has the AddWithValue method).
- Do never discard return values from save methods (we want to make sure that developers always check the return value of Save method, and not just discard it).
- Properties should not be set outside business objects (our biz objs should be stateless objects, so we don't want developers setting state outside of it)
And here are some rules we have in our to-do list to create:
- Standard Windows Form controls or ASP.NET controls should not be used directly. Subclasses should be used instead.
- Is there a way we can make sure that people do not query data in the database every time a property is accessed
- Disallow cyclic references between assemblies
- Verify that all SurpressMessage attributes have the Justification attribute set.
- Discourage use of hungarian notation, such as nNumber or cString or lcString or intCounter.
Also, for many of our custom rules, we want to make them configurable so that our clients can adapt them to their own needs. We're thinking of dropping XML files on the Rules folder and read settings out of there, kinda like the CustomDictionary.xml, but we haven't got to that yet.
Well, I think that's some feedback to get you started. 
Thank you for working close to the community on this.
.OpCode !=