Naming Conventions for SharePoint Developer /Administrator / Architect and End User

Looking for the naming convention for SharePoint farm to enforce in our enterprise’s Governance policy, saw so many blogs, books and MS article found some pieces of them useful so included in single place after copying from various sites, here it is worth to share all in single place.

Rule Number – 1- Keep Consistency – for all Visual Studio Solution or custom development solution should start the name as mention below.

<Company>.<Project or Department>.<Technology>.<Optional subdivision>

PASA.Symphony.SP.EventReceivers

Rule Number – 2 – Don’t abbreviate.   It might saving yourself typing a few characters really worth the inconsistency and ambiguity it creates

The naming conventions and document agrees and says only abbreviate when it’s necessary and the acronym is well known (in our organization name).  For example, we should use PASA instead of Panasonic Automobile Associations

Here are some ample namespaces / projects (again following the same naming schema from above):

Feature Name Description
PASA.TrainingPortal.SP Deploys most SharePoint artifacts such as pages, content types, site columns, lists, etc.
PASA.TrainingPortal.SP.EventReceivers Event Receiver for Eng. Process Portal Documentation
PASA.Marketing.SP.Workflow Custom workflows or workflow activities
PASA.Marketing.SP.Data Data access layer.  LINQ to SQL, Entity Framework classes, etc.
PASA.ProcessPortal.SP.Business Business logic layer
PASA.Symphony.SP.Services WCF Service layer for interacting with my application

Naming Conventions for SharePointSolution Packages

This means that the namespace, project name, assembly name, and package name are all the same

For example: PASA.Symphony.SP.wsp

When an administrator sees our package in the solution gallery later, this makes it easy for him/her to have an idea what your package does even if you didn’t provide a description.

Naming Conventions for SharePointFeatures

When it comes to features, we need to use the same techniques that we mentioned above about to name namespaces and projects.  This makes it easy to identify who made the feature and what it does.

The title of the feature is named ProjectName + Feature1.  In this case, the feature is PASA.Symphony.SP Feature1.  Note, that a space is there between the project name and Feature1.

Developers, please put a description on your feature.  It doesn’t have to be elaborate, just a quick sentence saying what it does.

Feature Name Description
PASA.Symphony.SP.ContentTypes Deploys content types and site columns (I like to deploy them in the same feature)
PASA.EBS.SP.Lists Feature that deploys lists or document libraries.  Can deploy multiple lists.  If you want to separate things out, you could have a feature PASA.EBS.SP.Lists.SharedDocuments
PASA.Engineer.SP.EventReceivers Installs the event receivers
PASA.Engineer.SP.Pages Deploys pages using the module element
PASA.ProcessPortal.SP.Workflow Custom workflows or activities
PASA.ProcessPortal.SP.Forms InfoPath forms

Naming Conventions for SharePointSite Columns / List Columns

Site Columns can be deployed by developers using Visual Studio or end users using the UI or both using SharePoint Designer.

Do not abbreviate.  On top of that, don’t use spaces. Leave out any special characters as well.  As example, I would use site column names such as these:

  • ProductCode
  • Color
  • SatisfactionRating

For site column or content type group names, it’s OK to use spaces between the words. So, an acceptable name would be Company Name Columns (where the name of your company replaces Company Name). This is better than “custom” because users will know that the columns were specifically created for your solution. But this alone isn’t enough.

Precede your group name with a period – for example “.Our Department Columns”. That little period has a really powerful effect – it will automatically force your custom groups to sort to the top of the list of groups that are exposed to your users. Try it, you’ll be surprised how much easier your life will be even as a developer. (I’ve asked a lot of really smart SharePoint architects and they assure me that adding a period to the front of custom group names will not cause any technical issues in your site. It’s just a naming trick to make your custom content types and columns sort “above” the “out of the box” ones.

Above are the initial name we specify when creating the column sets the internal name and it cannot be changed.  Once we have created the column, just edit it again and change the name.  It will then just change the display name and leave the internal name intact.  Do this and you will have site columns that will make both your end users and developers happy.

Naming Conventions for SharePointContent Types

Content Types go hand in hand with Site Columns, so we follow the same rules.  Avoid abbreviation when naming your content types.  We always prefer to avoid spaces in content type names

When you create Content Type names using CamelCase and then after the site is created, go back in to the settings and re-name the Title (or view name) to include spaces in the names. This will eliminate %20 in the URL and still support a friendly end user experience. (It’s like having your cake and eating it too!)

Naming Conventions for SharePointLists and Libraries

Choosing good names makes finding lists easier.  All of the other naming rules apply here

When you create List or Libraries or its View, names using CamelCase and then after the site is created, go back in to the settings and re-name the Title (or view name) to include spaces in the names. This will eliminate %20 in the URL and still support a friendly end user experience. (It’s like having your cake and eating it too!)

Rule No – 1 – Document Versions in Filenames
some people like to insist in placing version numbers in a document name. If you are going to do so, we have some recommendations for you. 1) be consistent, 2) never change the basename of the file, 3) place the version number at the end of the filename, but before the period, and 4) use dashes to separate major version number from minor version number. Example (“basefilename_v0-1.ext” or “base_file_name_v1-0.ext”).

Rule No – 2 – List & Library Names (in CamelCaseMePlease)
Use Camel Case format instead of spaces, dashes or underscores. Example (“ListNameForver” or “LibraryNameForever”)

Rule No – 3 – List or Library Names (Don’t Change the Name)
There are multiple reasons for this. The best reason is because system and external dependencies. Something might need to connect to it. So don’t change it

Rule No – 4 – Document Names – Use Underscores (_)

Naming Conventions for Pages or Folders

Choosing good names makes finding lists easier.  All of the other naming rules apply here

If we create Pages or Folders with CamelCase and then change the name to add spaces, the new URL will have %20’s replacing each space. For Page Names and Folder Names, it is up to you whether you can either live with the %20’s in URLs (PASA preference) or use underscores to separate words.

Naming Conventions for SharePointSites

For sites, I recommend following the same guidelines you do with lists.  This simply allows the URLs of sites to be typed in easier.  You can make the title whatever you want, just be consistent in the way you set the URL for the site.

When you create Site, names using CamelCase and then after the site is created, go back in to the settings and re-name the Title (or view name) to include spaces in the names. This will eliminate %20 in the URL and still support a friendly end user experience. (It’s like having your cake and eating it too!)

Naming Conventions for SharePoint Search

Of course, rules number 1 and 2 apply here.  We want consistency and we don’t want abbreviations.  End users don’t really ever see these settings, Content Sources are typically camel cased and contain spaces (i.e.: Local SharePoint Sites).  For managed properties, we should following the same naming conventions that we use for variables.  We want to avoid spaces as they get encoded as _x0020_.  End users often do see scope names throughout the SharePoint site on your master page or in the search center, so we need naming these with human readable text.  That means, use words, case things appropriately, and do use spaces. Some examples of scopes names would be Products, Accounting Documents, and All Sites.

Naming Conventions for SharePoint Variable Naming

All of the things we have discussed so far apply fairly well to variable naming as well. When working with the SharePoint API, we have a few things when working with classes like SPSite or SPWeb.  As we know, SPSite refers to a site collection and SPWeb refers to a site.  It’s confusing if you wanted to create an instance of an SPSite, what would you call it?  spsite?  currentSPSite?  We should not use like anything with SP in it of course. In the case of SPSite, we usually go with just siteCollection or maybe currentSiteCollection.  If we are working with multiple SPSite objects, we might name it somethingl ikesourceSiteCollection.   What about SPWeb?  For that I just use site or currentWeb.

Naming Conventions for SharePoint End user

General Issue we face

  • Rule Number – 1 – Keep Folder and File names short : You can enter longer descriptions in the ‘Title’ field (which do not build the URLs).Shorten Folder names using Datasheet View of the Folders in IE browser. Shorten File names using ‘Edit Properties’ of the file.
  • Rule Number – 2 – Do not use spaces in any Folder or File name (these appear as an ugly ‘%20’ in the URL). When a space is used in the URL, it gets converted to %20.  Your browser will let you type in the URL as a space or a %20 when you want to access that list they are a pain to find the space and then change this to %20, so avoid spaces if number one priority
  • Rule Number – 3 – Build no more than 3 levels of Folders.
  • Rule Number – 4 – For sorting by filename, use consistent naming conventions
    e.g.,  2015_01_15 sorts after  2014_11_07. One way to name is ‘YYYYMMDD_System_Name’, e.g.,  20150207_PM_Galayda
  • Rule Number – 5 – Don’t change the Name, Change the Title – When you create List or Libraries or its View, names using CamelCase and then after the site is created, go back in to the settings and re-name the Title (or view name) to include spaces in the names. This will eliminate %20 in the URL and still support a friendly end user experience. (It’s like having your cake and eating it too!)
  • Rule Number – 6 – Document Versions in Filenames
    some people like to insist in placing version numbers in a document name. If you are going to do so, we have some recommendations for you. 1) be consistent, 2) never change the basename of the file, 3) place the version number at the end of the filename, but before the period, and 4) use dashes to separate major version number from minor version number. Example (“basefilename_v0-1.ext” or “base_file_name_v1-0.ext”).
  • Rule Number – 7 – Document Names – Use Underscores (_)

Do not use illegal web characters ‘.'()’, ‘/’, ‘&’, etc.

Note- One of the downsides of the underscore recommendation is that it is difficult to distinguish the underscore from a space in a hyperlink, but this is usually only a problem if someone is trying to copy down your URL by hand.

Give your documents a “user friendly” name, use the Title column to create an additional name for your documents. In the Title column, spaces are fine. It’s a good idea to always have a non-blank Title because the Title is displayed by default in search results and in Content Query web parts.

  • Rule Number – 8 – Try not to use hyphens or dashes to separate words. While search engines typically also recognize a dash or hyphen (“-“) as a valid word separator, I prefer the underscore because hyphens are used as break points to wrap text on separate lines. URL’s that contain hyphens often cause problems in email, a problem that I would bet that all of us have encountered at one time.

About Krishana Kumar

Krishana Kumar is SharePoint Architect/Trainer having Architecture experience with high volumes at Enterprise level and global scale - creation of highly scalable solutions with global user base and geographically distributed architectural components. Good knowledge of SharePoint best practices and governance models. I hold Two Master degree in Computer Science with over 11 years of experience working on Microsoft Technologies specially SharePoint, Project, .NET and other Information Worker Technologies. Having good exposer in Client side scripting Angular.js, backbone and Node. I am currently responsible for SharePoint Infrastructure set up and leading teams in various medium and large scale projects, architecting, designing & installing SharePoint farms, developing custom components,, and providing advanced SharePoint administration and development training to teams and customers. I regularly speaks in various SharePoint User Groups and other Events. I have MCSA Windows Azure, MCSA Office 365, MCSE & MCSD SharePoint 2013, Microsoft Certified Developer (MCD) and holds MCPD, MCTIP and MCTS for SharePoint 2010, MCTS MOSS 2007 & WSS 3.0, MCPD, MCITP (EPM 2010 & 2007) and MCSD .NET.
This entry was posted in General Interest. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *