Explanations are good. Here are mine, reprinted for convenience:
Throwing an exception is a very expensive operation--basically the most expensive thing short of calling external resources. Think of an exception as making the computer beep twice and pause for two seconds, then think if you actually want to use one in that place.
2. Thou shalt not use exceptions to manage program flow.
The idea here is to facade things like the Session object away. For example, add a property to your base page class such as the below:
3. Thou shalt wrap calls to external resources, such as configuration values or session variables in strongly typed properties.
This means that your application no longer has to worry about the specifics of the username storage, it just pulls the property. So when you decide that it is better to store it in a cookie, all you need to do is change the property. Moreover, when one is storing complex types, it centralizes all the casting.
protected string UserName
We had a nice little debate on this subject on page one. In general, one does not want to use data sets even if they make things nice and easy. The main drawback is that architectually, using a dataset means the front end application is quite aware of the back-end database and business logic tends to bleed into the presentation layer. One ends up with a 2.5 tier solution oftentimes. The other major disadvantage of a dataset is they tend to get very inefficent, especially for large datasets. Bottom line is to only use them where having an in-memory representation of the database makes sense.
4. Thou shalt not use DataSets in web applications.
I hope this transtlates . . . .
27. Thou shalt use common sense.
Best explained by Benjymouse above.
28) Thou shalt not use Server Side Includes (<!-- #INCLUDE -->). Thou shalt use user controls or master pages.
Also debated & explained above. One should never, ever use Response.Write() in the code behind/code beside parts of a page (that is the back-end code) as it does horrid things to the .NET page lifecycle model. If one must emit text to the output stream, send things to the HtmlTextWriter that stores the response instead.
29) Thou shalt not use Response.Write. This includes the shorthand <%= somestuff %>.
Inline the debate is a bit thicker. I, myself, use databinding (<%# somestuff %> to page-level variables rather than including calls to Response.Write (which can be shorthanded as <%= somestuff %>).
Hope this helps.