Rules To Better SharePoint

1. Never touch production environment with SharePoint designer.

   • SharePoint designer can silently reformat your code and introduce errors.
   • If you modify any masterpage or pagelayout file with SharePoint designer, it becomes ghosted. This means that SharePoint is now looking at a customised version stored in the database rather than the version on the file system. You then can't deploy changes using SharePoint solutions & features.

2. Developers should work on all custom webparts in their own SharePoint development environment.

   This is to prevent their work affecting other developers. Sort of things you can expect to happen:
   
   • IIS resets need to be done frequently, which stops the SharePoint website working.
   • Custom webparts can easily introduce memory leaks which can stop SharePoint working.

3. Make small incremental changes to your VSeWSS projects.

   • When working on packaging SharePoint artefacts into Features & Solutions, you should always make small incremental changes to your VSeWSS projects. Each time you should build & deploy to check you haven't broken anything.
   
   
   • You should regularly make labels in TFS so you can quickly compare your changes against previous working versions to identify problems.



4. Customize your SharePoint webparts.

   Try to customize existing out-of-the-box SharePoint webparts before you roll your own.

5. Do you know to develop inside a VM?

   All SharePoint customization and development must be done on a Virtual Machine.

   1. It's very important to correctly setup a SharePoint environment for development. Correctly configured, this will save you a lot of trouble later on.
   2. From time to time, you can seriously damage a SharePoint installation during development and it is best not to install SharePoint on your everyday working machine. Additionally, when you start a new SharePoint project you don't want to carry all the luggage from a previous customization that could potentially affect your new project.
   3. Virtual machines can be fired up and shut down easily
   4. Virtual machines can be relocated on a different server and thus it doesn’t waste developers' own computer resources
   5. Virtual machines can be copied and brought to a client for demostration.
   6. Very easy for someone to quickly create a new SharePoint server to quickly test or experiment with SharePoint.
   7. Bad: There might be more work required to activate additional servers.
   More info on setting up SharePoint VM
   

6. SharePoint version?

   When your SharePoint website was built successful, you need to create SharePoint version to let users know what version is it

   
   More info on better code
   

7. Work with SharePoint designer.

   • Don't use inline CSS
   • Always put <div class="..."> wrappers around SharePoint controls. This allows us to define styles for SharePoint controls. It is possible to use CssClass like ASP.NET, but then we lose control to SharePoint regarding how that control will be rendered.
   • Naming convention for control id! Don't get lazy.
   • Turn off Auto indent.
     

8. Do you always use Site Columns instead of List Columns?

   A site column is created on a site level and visible to all lists and content types within that site (and subsite).

   • New in SharePoint 2007 (WSS v3)
   • The same column can be added to different Content Types, lists, list templates
   • Allows you to make modifications at one place and SharePoint can apply the changes for you across the different lists and content types (doesn't try to fix the content for you though)
   • More visibility of the customization we are applying to the SharePoint website
   • Make sure the site column is added to our own group description such as "SSW Columns"
     

Acknowledgements

John Liu