Checklist for coding in c# for SharePoint Development

Checklist for SharePoint Development

·         Does my code properly dispose of SharePoint objects?

·         Does my code cache objects properly?

·         Does my code cache the correct types of objects?

·         Does my code use thread synchronization when necessary?

·         Does my code work as efficiently for 1,000 users as it does for 10 users?

·         Code should not include hardcoding of any type

Naming Conventions

·         Coding should follow a proper naming conventions, either Camel or Pascal casing, use PascalCasing for class names and method names. use camelCasing for method arguments and local variables

·         Make sure to not to use underscores in identifiers. Exception: you can prefix private static variables with an underscore.

·         Make sure to use noun or noun phrases to name a class

·         Prefix interfaces with the letter I.  Interface names are noun (phrases) or adjectives.

·         organize namespaces with a clearly defined structure

o   // Examples

o   namespace Company.Product.Module.SubModule

o   namespace Product.Module.Component

o   namespace Product.Layer.Module.Group

·         do not use Hungarian notation or any other type identification in identifiers

·         // Correct

·         int counter;

·         string name;

·          

·         // Avoid

·         int iCounter;

·         string strName;

·         Controls Naming Convention:-

o   Textbox: txtName

o   Button: btnName

o   Label: lblName

o   Panel: pnlViewer

o   Image: imgName

Properties:s

o   Use noun or noun phrase with Pascal case like UserID, Password etc.

Methods:

o   Use verb or verb phrase with Pascal case like InsertQuery(), GetUserInfo() etc.

Coding Flow and Comment

·         Write only one statement per line.

·         Write only one declaration per line.

·         Add at least one blank line between method definitions and property definitions.

·         Place the comment on a separate line, not at the end of a line of code.

·         Begin comment text with an uppercase letter.

·         End comment text with a period.

·         Insert one space between the comment delimiter (//) and the comment text

·         Do not create formatted blocks of asterisks around comments.

·         Either use Camel case like userID or Pascal case like UserID

Object Model

·         Make sure SharePoint objects like SPSite and SPWeb are being disposed properly. Do not.Site or dispose of any item returned directly from the Microsoft.SharePoint.SPContext Microsoft.SharePoint.SPContext.Web property except when you obtain reference to these using a constructor or when you use AllWebs.

• The SPSiteCollection.Add method creates and returns a new SPSite object. You should dispose of any SPSite object returned from the SPSiteCollection.Add method.
• The SPSiteCollection [] index operator returns a new SPSite object for each access. An SPSiteinstance is created even if that object was already accessed. The following code samples demonstrate improper disposal of the SPSite object.
• The SPSite.AllWebs.Add method creates and returns an SPWeb object. You should dispose of anySPWeb object returned from SPSite.AllWebs.Add.
• The SPWebCollection.Add method creates and returns an SPWeb object that needs to be disposed.
• The SPSite.AllWebs [] index operator returns a new SPWeb instance each time it is accessed.
• The OpenWeb method and SelfServiceCreateSite method (all signatures) create an SPWeb object and return it to the caller.

·         The Microsoft.Office.Server.UserProfiles.PersonalSite returns an SPSite object that must be disposed

• The SPWeb.Webs property returns an SPWebCollection object. The SPWeb objects in this collection must be disposed.
• The SPWeb.Webs.Add method (or Add) creates and returns a new SPWeb object. You should dispose of any SPWeb object returned from this method call.
• The SPWeb.Webs[] index operator returns a new SPWeb object for each access

Using Objects in Event Receivers

Do not instantiate SPWeb, SPSite, SPList, or SPListItem objects within an event receiver. Event receivers that instantiate SPSite, SPWeb, SPList, or SPListItem objects instead of using the instances passed via the event properties can cause the following problems:

• They incur significant additional roundtrips to the database. (One write operation can result in up to five additional roundtrips in each event receiver.)

Calling the Update method on these instances can cause subsequent Update calls in other registered event receivers to fail.

• Do not use an unbounded SPQuery object.
• An SPQuery object without a value for RowLimit will perform poorly and fail on large lists. Specify aRowLimit between 1 and 2000 and, if necessary, page through the list.
• Use indexed fields.
• If you query on a field that is not indexed, the query will be blocked whenever it would result in a scan of more items than the query threshold (as soon as there are more items in the list than are specified in the query threshold). Set SPQuery.RowLimit to a value that is less than the query threshold.
• If you know the URL of your list item and want to query by FileRef, use SPWeb.GetListItem(stringstrUrl, string field1, params string[] fields) instead.

Exception Handling

·         Make sure to use Try-catch and using statements in exception-handling

·         Don't catch (Exception) more than once per thread

·         Cleanup code should be put in finally blocks

·         Don't use exception handling as means of returning information from a method

·         Errors/Exceptions must be logged

·         Switching ON and OFF the AllowUnsafeUpdates option, as and when appropriately.

·         Disposing the SPSite objects after usage.

·         Disposing the SPWeb objects after usage.

·         Avoid disposing objects derived from SPContext.

·         Try the "Using" clause - to avoid the overhead of disposing objects explicitly.

Customization

·         Don't change any default SharePoint installation files

·         Custom master pages will be based on a copy of the default master page

·         Avoid customising content pages with SharePoint Designer

·         Avoid inline server side script in pages

·         All applications should be globalised and then localised to English

·         Package all web parts and templates as features

Deploy code 

Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding.

Configuration

·         In a shared environment no AppSetting entries are generally allowed in the web.config configuration file of WSS. Instead consider using your own application specific configuration file and store along within your application or feature folder. The feature.xml file should be used for storing Feature properties. A SharePoint list can be considered for storing common configuration data

Features:-

·         All Feature scope should be Site collection scope or lower instead of at the Web-application level. If features can be re-used then they could be deployed at the web-application level.

·         Feature Title should be appropriately named.

·         Provide full description which should include information on the usage, any restrictions, and dependencies on other features, assembly, ownership and contact information. This description should be included in the Feature.xml in addition to any documentation