Becky Bertram recently blogged about Visual Studio project organisation for SharePoint. I agree with most of her points, and below are 3 additional conventions I’d suggest to others:

1. Always group SharePoint project items (SPI) into folders by project item types

Put all content type SPIs into a folder called ContentTypes, all site column SPIs into a folder called SiteColumns, and so on. This allows the content of the project to be more discoverable at a glance. For example, you can quickly get a high level idea of the content being deployed by the project below:

2. Always append the SPI type to the name of the SPI

If your project has a Feedback content type and a Feedback list instance, then name the project items as FeedbackContentType and FeedbackListInstance. Do this for all SPIs in the project. This helps identify the item in views such as the Feature Designer, and particularly the Package Explorer.

I find myself using the Package Explorer quite a bit these days. This is because Visual Studio automatically adds new SPIs to the last feature added to the project – and often this is not where you want the SPI to go. Using the Package Explorer, you can quickly verify the content of your features, and can easily cut/paste SPIs between features to correct the location of SPIs misplaced by Visual Studio.

3. Getting the feature boundary right

How many features should you have? Which SPIs should go into which features? These are the guiding principles I use to address these questions:

1. Reduce the number of features where possible. The more features the more maintenance and administration overhead.
2. Define feature boundary by functionality. Group SPIs related to a particular functionality into one feature. Each feature should represent a unit of functionality – the more coarse the unit the better. This is so that it may be possible to a) enable a functionality by activating only one feature, and b) deactivate the feature without affecting other functionalities.
3. If a functionality could be reused elsewhere, group the SPIs supporting this functionality into their own feature. This is so that this functionality (and only it) could be activated in other locations (e.g. in a different site collection) without also activating other components that are not relevant to the functionality and the alternate location. Sometime ago I made a mistake of putting the masterpages, CSS, page layouts and other stuffs into one feature. After deployment, a new site collection was deployed to the same farm and needed to use the same masterpage to achieve the same corporate branding. We activated the feature I originally built, but this also deployed the page layouts and other stuffs that are not applicable to the new site collection.

After all however, I believe there is one rule that rules them all, and that is consistency. Whatever you choose to do, make sure you do it consistently.