Programming Practices

1. Experienced developers follow numerous programming practices or rules of thumb, which typically derived from hard-learned lessons. The practices listed below are not all-inclusive, and should not be used without due consideration. Veteran programmers deviate from these practices on occasion, but not without careful consideration of the potential repercussions. Using the best programming practice in the wrong context can cause more harm than good.
2. To conserve resources, be selective in the choice of data type to ensure the size of a variable is not excessively large.
3. Keep the lifetime of variables as short as possible when the variables represent a finite resource for which there may be contention, such as a database connection.
4. Keep the scope of variables as small as possible to avoid confusion and to ensure maintainability. Also, when maintaining legacy source code, the potential for inadvertently breaking other parts of the code can be minimized if variable scope is limited.
5. Use variables and routines for one and only one purpose. In addition, avoid creating multipurpose routines that perform a variety of unrelated functions.
6. When writing classes, avoid the use of public variables. Instead, use procedures to provide a layer of encapsulation and also to allow an opportunity to validate value changes.
7. When using objects pooled by MTS, acquire resources as late as possible and release them as soon as possible. As such, you should create objects as late as possible, and destroy them as early as possible to free resources.
8. When using objects that are not being pooled by MTS, it is necessary to examine the expense of the object creation and the level of contention for resources to determine when resources should be acquired and released.
9. Use only one transaction scheme, such as MTS or SQL Server™, and minimize the scope and duration of transactions.
10. Be wary of using ASP Session variables in a Web farm environment. At a minimum, do not place objects in ASP Session variables because session state is stored on a single machine. Consider storing session state in a database instead.
11. Stateless components are preferred when scalability or performance are important. Design the components to accept all the needed values as input parameters instead of relying upon object properties when calling methods. Doing so eliminates the need to preserve object state between method calls. When it is necessary to maintain state, consider using alternative methods, such as maintaining state in a database.
12. Do not open data connections using a specific user's credentials. Connections that have been opened using such credentials cannot be pooled and reused, thus losing the benefits of connection pooling.
13. Avoid the use of forced data conversion, sometimes referred to as variable coercion or casting, which may yield unanticipated results. This occurs when two or more variables of different data types are involved in the same expression. When it is necessary to perform a cast for other than a trivial reason, that reason should be provided in an accompanying comment.
14. Develop and use error-handling routines. For more information on error handling in Visual Basic, see the "Error Handling and Debugging" chapter of the Microsoft Office 2000/Visual Basic Programmer's Guide, available in the MSDN Library. For more information on error handling and COM, see "Error Handling" in the Platform SDK. For more information on error handling for Web pages, see http://msdn.microsoft.com/workshop/author/script/weberrors.asp.
15. Be specific when declaring objects, such as ADODB.Recordset instead of just Recordset, to avoid the risk of name collisions.
16. Require the use Option Explicit in Visual Basic and VBScript to encourage forethought in the use of variables and to minimize errors resulting from typographical errors.
17. Avoid the use of variables with application scope.
18. Use RETURN statements in stored procedures to help the calling program know whether the procedure worked properly.
19. Use early binding techniques whenever possible.
20. Use Select Case or Switch statements in lieu of repetitive checking of a common variable using If…Then statements.
21. Explicitly release object references.

Reference: MSDN