Best Practices for SharePoint development

Best Practices for SharePoint Web part Development:

1. Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed.
2. The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower.
3. You use the SharePoint Web part infrastructure’s standardized set of connection interfaces for Web parts to exchange information with each other at run time.
4. Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.
5. All custom Web parts utilize the SharePoint architecture to ensure consistent behavior across the application for functionality such as single sign-on, feature deployment, and so on.

Best Practices for General SharePoint Software Development:

1. Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
   
   
2. You use delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.
   
   
3. Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
   
   
4. Highly privileged assemblies are separated from lower privileged assemblies.
5. If an assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is in a separate assembly.
   
   
6. You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.
   
   
7. You use .NET Framework 2.0, 3.0, or 3.5.
   
   
8. You use a single .NET Framework version. You do not mix multiple versions.
   
   
9. Your code is 64 bit compatible.
   
   
   
10. Your application does not try to directly access any SharePoint databases. Data stores in SharePoint databases are only updated by using the SharePoint object model.
    
    
11. You avoid hard coding strings and labels. You use resources or language files instead.
    
    
12. When referencing the SPWeb or SPSite objects, you employ a using statement or, alternatively, you use an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.
    
    
13. You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose the cache expiration (duration) as a Web part property.
    
    
14. When packaging your solution, you include a Code Access Security policy for the solution and, if necessary, include your assembly in the Safe Controls list though the solution.
15. When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.
    
    
16. If you need to update multiple list items by using remote code, you use the Web service to update list items. You only use SPListItem.Update() if you have to update more than one item at a time by using local OM-based code.
    
    
17. When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.
    
    
18. The solution uses the AppSettings object to implement XML mapping. (This can be provided by using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.
    
    
19. Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.
    

More on http://bestofcyber.wordpress.com