Avoid hardcoded urls, emails, accounts in code.
The SharePoint object model always creates new SPSite objects with the zone set to Default, even if the code that’s creating the object is running under a SharePoint extended web application associated with a zone other than Default.
Catch block should include ULS logging output or re-throw.
This class and its members are reserved for internal use and are not intended to be used in your code.
You do not have elevation of privilege when using SPSecurity.RunWithElevatedPrivileges in (1) Workflow, (2) Timer Job, (3) Feature Receiver or (4) Event handler (SPItemEventReceiver, SPListEventReceiver,SPWebEventReceiver, SPWorkflowEventReceiver) in the follow cases:
SPContext objects are managed by the SharePoint framework and should not be explicitly disposed in your code.
Avoid using SPContext.Current outside of web request context.
How do we know what people want – folder, inside folder, or just items? SPQuery has an "affected scope"...
Avoid feature activation via code. It leads to “black boxed” feature activation chain, which leads to pooor overall solution quality, traceability and supportability.
For non document library it returns null.
It might be good to use SPMonitoredScope construction in visual components code, hence it might use with together developer dashboard.
SharePoint 2010+ has security feature to all objects inheriting from SPPersistedObject. This feature explicitly disallows modification of SPPersistedObject objects from content web applications (not CA).
How do we know what people want – folder, inside folder, or just items? SPQuery has an “affected scope”.
Sending an e-mail from a WCF service when SPContext is not available could fail. As a workaround, you have to prevent the mail function from reading the current context by using HttpContext.Current = null. If it can’t, it will retrieve the right context and it will then work.
How do we know what people want – folder, inside folder, or just items? SPView has an "affected scope".