Skip to Content

SharePoint coding standards

Some standards I collected from the internet and thought off for building SharePoint solutions

• Code development is done using C# and Visual Studio 2010. Microsoft default coding standards are to be followed including (but not limited to):
o C# coding conventions
o Follow MSDN best practices for developing SPS solutions
o Naming conventions
o Design Guidelines for Developing Class Libraries
o security
• If {customer} is owner of the sourcecode, every new version of the solution must be accompanied by the latest source code. The source consist at least of a full development solution including SLN file, feature, manifest and package files. It should be fairly simple to open the solution in Visual Studio 2010 and deploy it directly to SharePoint using Visual Studio own SharePoint addins.
• The code should be inline documented using XML Comments (Visual Studio default). Comments should be as comprehensive as possible. All comments are done in English. Mandatory tags are;

, .
• All code must be fully tested. Every version of the end product must be tested for memory leaks using SPDisposeCheck.
• Use of external assemblies is allowed as long as the source code is included in the deliverable and the source code complies with {customer} code standards.
• No out of the box SharePoint files in the 14 hive will be overwritten.
• Logging must be fully configurable and on a per (functional) solution base be separated. Verbose logging (tracing) should be an option, errorlogging is mandatory. Besides logging to its own logfile, the application should also log errors to the windows eventlog for further support (scom). Minimal logging contains date/time stamp, errorcode, errormessage and stacktrace.
• All language related strings should be held in separate (not embedded) resource files, so that administrators can change values
• Solutions should comply with regional settings of {customer}servers/SharePoint settings and obey the {customer} policy standards.
• Code should be written with performance in mind. Retrieving 100 records to fetch 1 field is not acceptable. Code should be lean and mean. Keep methods/members clean and simple, refactor if possible.
• Supplier must use some sort of sourcecontrol mechanism and store the code in this system.
• Creation of site/list templates must be fully forward/backward compatible. Future updates may never break this compatibility. Site templates in 2010 are deprecated.
• STP files are not allowed as they are not updatable
• Changes to SharePoint central admin are only allowed if web development team has authorized this.
• Catch errors as specifically as possible, die gracefully and appropriately. Try to catch every situation, so that SharePoint is not responsible for error handling.
• All supplied solutions must be in release mode
• All SPSite and SPWeb objects must be manually disposed
• Preferred option to communicate with SharePoint is through SPS objectmodel (client OM is allowed). If necessary, webservice calls are allowed. There should never be direct SQL read/writes to any of the SharePoint databases. Use of Out of the Box available options are allowed (like webdav etc).
• Custom databases are not allowed. Storage must be done within SharePoint (lists/libraries)
• Webpart properties must be fully documented. Description must be comprehensive and in English.
• Flash parts are not allowed, Silverlight is allowed. Use of JQuery is allowed, custom javascript is allowed.
• Caching must be used as much as possible; but always within the guidelines of Microsoft.
• Assemblies must be downwards compatible, AssemblyVersion must not be changed. If existing interface must be changed, overloads should be used.
• The assembly file version number should be as the solution version number and must be incremented on every build to ease communication.
• In the top section of each file (code, xml, aspx, etc) supply the following information:
o Company name and copy rights ({customer} or otherwise)
o Author name
o File
o Purpose
o Create Date
• Assembly name must comply with naming [SKGSharePoint].[Supplier Name].[Solution name].[function name].dll
• Ensure that each feature folder name and title should follow this format: [SKGSharePoint].[Supplier Name].[Solution name].[Feature Name]
• Solution naming convention must be descriptive: [SKGSharePoint].[Supplier Name].[Solution or module name]_[Version number].
• Referenced assemblies should not be set to copy local = 'true'.
• Application settings must be set using a SharePoint list. If necessary application config file may be used. The config naming convention should be [SKGSharePoint].[Supplier Name].[Solution name].config.

• All solutions must be packed in 1 WSP file. Functional related features should be built into one solution.
• Solutions are not allowed to write anywhere on the SharePoint servers expect for the under TEMPLATE folder in the 14 hive, (only in its own subsubfolder). Adjustments to web.config are allowed but must be documented (except for the changes to the SafeControls section).
• Changes to the inetpub folder are allowed, but only on the level of the corresponding webapplication (\inetpub\wwwroot\wss\VirtualDirectories\[port]\)
• Solutions must be scoped by site (or lower).
• No changes are allowed to IIS metabase.
• Powershell scripts to deploy the solution should accompany the solution.
• Manual actions, extra script or SharePoint designer actions are not allowed.
• If the solution is an update of an existing solution, powershell scripts should accommodate an upgrade instead of a retract-deploy scenario.
• After deactivation features are not allowed to leave files or settings on the SharePoint system. This requirement should be tested and validated by supplier. If the feature creates a list or library that contains user data, the feature should not delete this list.
• GAC deployment is allowed if it is fully documented (and explained).
• If workflows are necessary, Nintex is the preferred option. If this is not possible, workflows must be created using Visual Studio 2010. SharePoint designer is not an option.
• All solutions must be accompanied by an installation guide which contains the following
o Solution name and version number.
o Targeted environments for installation.
o Software and hardware Prerequisites: explicitly describes what is all needed updates, activities, configurations, packages, etc. that should be installed or performed before the package installation.
o Deployment steps: Detailed steps to deploy or retract the package.
o Deployment validation: How to validate that the package is deployed successfully.
• All solutions must be accompanied by an technical design document
• {customer} Web Development Team is responsible to register ID’s for site and list templates. Suppliers must always check if used ID’s are available.
• Site definition names should begin with “SKG_”.

• Code should apply Code Access Security to minimize footprint
• Any "abnormal" security requirements (runwithelevatedprivileges etc) should be fully documented in code and in documentation
• Integrated security (NTLM) should be used as authentication mechanism. Authorization should be done through SharePoints own user-role system. No user-id/passwords should be stored in the SharePoint system.