SP 2010 Best Practices

1. Ensure Object Disposal by using Dispose method, using clause or try, catch, and finally blocks

2. Create lists and libraries using appropriate list definition templates

3. Refactor your project solution into appropriate projects to have clear demarcation of various object. Use a separte project for data access, a separate project for list instantiation, and a separate project for logging, and another project for SharePoint artefacts like webparts, custom pages etc
4. Always use the developer dashboard on all the custom pages that are developed. This gives an overview of the performance of the page
5. The SPSiteCollection.Add method creates and returns a new SPSite object. You should dispose of any SPSite  object returned from the SPSiteCollection.Add method.
6. The SPSiteCollection [] index operator returns a new SPSite  object for each access. An SPSite instance is created even if that object was already accessed.
7.The SPSite.AllWebs.Add method creates and returns an SPWeb  object. You should dispose of any SPWeb object returned from SPSite.AllWebs.Add.
8.If the object is obtained from the SharePoint context objects (GetContextSite  method and GetContextWeb method), the calling application should not call the Dispose  method on the object. Doing so may cause the SharePoint object model to behave unpredictably or fail. This is due to an internal list that is kept in the SPSite and SPWeb objects derived in this way. Internally, the object model enumerates over this list after page completion to dispose of the objects properly.
9. Always use SPQuery object and CAML Query to filter data from lists. Iterate through collections only after filtering the collection as required
10. While using images always set the ALT property to the IMG tag.
11. Create lists and columns with a name WITH NO SPACES
12. WebParts: Always initialize your controls in the CreateChildControls method.
Call the EnsureChildControls method in your code
Do not use the Render() method while developing a webpart in SharePoint
13. Frequently check the entries in the log for - The total number of SPRequest objects, An SPRequest object continues, An SPRequest object was garbage collected
14.Make sure that the containers like lists and libraries follow the recommended guidelines on number of items in it viz 2000 items in SharePoint 2007 and 5000 items in SharePoint 2010
   a. Implement a timer job that deletes items from list regularly if they are not needed
   b. Store items in folders rather than storing them directly in list
15.Use the SPQuery.ViewFields property to get only the required number of fields in the dataset
16. SPDisposeCheck tool on all code before deploying outside of you development environment
17.Wrap all your custom code that runs with full trust in SharePoint using the SPMonitoredScope class.

using (new SPMonitoredScope("My Code"))
{
    //Your code
}


using (new SPMonitoredScope("My Scope Name",1000,new SPRequestUsageCounter(3),new SPSqlQueryCounter()))
{
    //Your code
}

You can use any of the following classes to monitor specific code sections depending on the scenario SPCriticalTraceCounter (critical events and asserts), SPExecutionTimeCounter (track execution time for your scope), SPRequestUsageCounter (rack the number of SPRequest objects your code uses), SPSqlQueryCounter (tracks the number of SQL queries for your scope).
18. Database related -
       a. SharePoint runs a nightly timer job to rebuild indexes and update statistics, so be sure that this job is created and running.
       b. Always pre - grow all your databases, as it is an expensive operation for SQL Server to autogrow databases
19. Do not use CSS inline styles but use CSS files and appropriately markup the CSS styles using theme attributes

20. At all possible times develop sand-boxed solutions, and use full-trust proxies to do the necessary code plumbing 21.Allocate a pre-defined quota to all your sandboxed solutions, and regularly monitor their usage and fine tune them 22. Validate all the sandboxed solutions using the SPSolutionValidator class 23. The 'site.GetFile' method returns an SPFile object even when you pass the path to a site page that does not exist.You should inspect the Exists property before attempting to access any of its other methods. 24. Recompile all your sandbox solutions by referencing it to the Sandboxed Microsoft.SharePoint.dll present in the UserCode directory in 14 hive to make sure that none of the API are calling methods which are restricted in SSs. 25. Indexing should be done on the columns that are used for filtering in the LINQ/CAML queries 26. use Power Shell scripts for deployment  27. Do not use the Workflow History list heavily. Implement some other logging mechanism if needed to log heavily 28. Make sure to create a root site in a site collection for a given web application, else it might give issues when accessing web services via that web application 29. Use SPWeb.ProcessBatchData method for bulk deletion of items in a list 30. Do not use delay activities in custom workflows as they do not fire always. It is a known issue. Try to implement Timer Jobs instead 31. In scenarios where a field’s display name could change, it is a safer bet to access the field within a Fields collection using the GetFieldByInternalName method 32. Create Site columns and custom content types in the site columns gallery or content types gallery of top-level sites so that they are made available on a site collection–wide basis 33. Always use the SPList.EventReceivers.Add(GUID) overload while registering event handlers programmatically. This helps to check if the event handler is already existing or not, and its easier to delete it in Feature Deactivation 34. It is generally recommended that you avoid custom site definitions when designing and developing SharePoint solutions