Best Practices for a .NET Extension or Plug-In

These are best practices that I created for writing a .NET Extension or Plug-In so some of the references and nomenclature are .NET specific, but the principals and ideas can be extended to any programming language or application design.

Best Practices for Writing a Good Extension or Plug-In:

1. Any extension should have logging features (and ideally support verbose, error, warning messages). Most applications provide some sort of logging capabilities you can use or extend. This is preferred to designing your own simply because you would have to monitor two sets of logs not to mention the additional configuration, and maintenance of adding a second logging mechanism. If you do have to add your own logging, try to leverage an existing logging infrastructure: log4net, Microsoft Enterprise Library.
2. If possible avoid any additional (and most importantly external) database or service calls. Aside from the performance hit this can add, your introducing potentially volatile resources that will affect the host systems ability to work properly.
3. Settle on a single purpose or function for your extension. Don't try to make it do several things, and work in several different functions. It's hard to understand, maintain, and a nightmare when 'something' inside the extension/plug in goes bad.
4. Limit external dependencies. If at all possible you want your extension/plug-in to be entirely self-sufficient. Any information or exchange should be provided by the host system via a state bag, or in the direct actionable items available.
5. Document as much of the plug-in as possible within the code module. Include references, and be explicit. You should always document, but people tend to forget about extensions and plug-ins. You write them, they get deployed, and then days, months, years later... doom. The more that's in the code when you open it back up the quicker you can fix it.
6. Handle and dispatch exceptions in almost all cases. If you can't handle the exception, and it needs to be raised to the host system, then make sure your logging (see #1 on this list) records the exception with as much information as possible. In my experience a host system most often reports very little useful information or (as in one case I remember) it reports absolutely nothing.
7. Design the functionality of the plug in! So many times, people try to write everything inline for a plug-in rather than following the same coding practices that they would in any other application or feature. 
8. Favor robust naming if your plug-in and if possible the methods, functions, and variables within it. Often when dealing with a plug-in it needs to be self explanitory to the infastructure dude, the end-user, and in almost all cases other people.
1. Here's a quick example: 
1. MyCompanyNamePlugIn - Seriously? That does that do? 
2. MyCompanyUpdateCreatedDateOnNewRecordPlugIn - Ok, really simple. Want to guess?
9. Consider interprocess communication if execution is lengthy, intensive, or will impact the performance of the host system. If the action is lengthy or is going to impact the host system, then consider having your plug-in use a queue or call a service for executing the action. If performance is going to be impacted in an extreme negative, consider external executing with a service-bus or queuing system.

References:
Best Practices for Developing Your First Ektron Site
Best Practices in Plugin Development (WordCamp Seattle)

Resources:
log4net
Microsoft Enterprise Library.