Recently my team got burned by a SharePoint consulting company that did some shoddy work.  I don't blame them entirely, we should have been more specific about our requirements and standards.  But at the same time, their work has been making me groan all week.  They updated out of the box master pages through SharePoint designer, created site templates using .stp files through the GUI, and they hard coded static links into their custom web parts that broke when we deployed them to a different location. 

So all this has shown me the value of good standards and communication.  I'm starting with the standards part.  Here's my crack at a list of standards for developing custom SharePoint functionality.  Although I've been programming in SharePoint 2007 since the beta, I know I still have loads to learn, so I wanted to enlist the help of the internets on this one.  What is standard operating procedure for you when you develop in SharePoint?  What are the musts, and what are the nice to haves?  Give me all the gory object modely details.

My Current SharePoint Development Standards List
General

• All custom SharePoint work must be deployed through SharePoint solutions (.wsp files)
• We will not import or restore any backups of sites developed by third parties. This shouldn't be a problem as all custom work will be deployed through solutions and features anyway. I wanted to avoid importing hidden designer hacks, but J.D. Wade brought up a good point, we might need to import actual content, so we can't completely write this off.
• All functionality and customizations must be documented
• Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Code

• Web parts must be deployed using our custom feature receiver (we can provide source to third parties working with us).
• Custom code must be checked for memory leaks using SPDisposeCheck.
• For site definitions, use a minimal site definition with feature stapling.
• Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

12 Hive Deployment

• No out of the box SharePoint files in the 12 hive will be overwritten
• Images deployed must be deployed into an RGA/ProjectName folder

SharePoint Designer

• SharePoint designer updates are generally not allowed. The only exception to this rule is for creating DataForm web parts.
• DataForm web parts must be exported through the SharePoint GUI and solution packaged for deployment as a feature.
• Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, make edits, then solution package the master page for feature deployment.
• No SharePoint Designer created workflows. These are not portable and cannot be packaged for solution deployment.

InfoPath

• custom ASPX forms are preferred over InfoPath forms. They are easier to support, debug, and upgrade.
• InfoPath forms must be browser compatible. We run all our InfoPath forms deployed through forms services through the browser.
• If the InfoPath form has code behind or needs full trust it must be solution packaged and deployed through central admin. (see my previous post for reference)
• If InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form. Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

Update 08-17-2020: Richard Harbridge has taken this list and combined it with other SharePoint development standards from around the internets to form a bigger list of standards.