ASP.NET Bad Practices: What you shouldn’t do in ASP.NET (Part 2)

This is the second article of ASP.NET Bad Practices: What you shouldn’t do in ASP.NET series of blog post. You may want to take a look at the first article here. Now let’s carry on to discuss the next 5 taboos in ASP.NET.

6. Leftover Debug Code

DO NOT

*in the production

WHY

• Longer compilation time
• Longer code execution
• More memory usage at runtime
• Images and scripts are not cached

You can read the post by Scott Gu and Scott Hanselman on how serious this bad practice is.

DO

Always set debug=“false” in the production

*By default, web.config transformation will transform the debug to false during publishing. So don’t try to be naughty by turning it to true.

7. Improper usage of static Variable

TRY TO AVOID

Using static variable in ASP.NET improperly

UNLESS you know what you’re doing and the impact

WHY

• Inconsistent value during concurrent access
• It will be shared across other requests / users
• Value might be overridden by one and another

PREFER

• Read only scenario => use const or readonly
• Maintaining value when post back => use viewstate
• Maintaining value across multiple page => use session
• To cache the data => use cache

However

Static variable is useful when:

• Locking object to avoid multi-write synchronization
• Global-wide level object sharing (static VS application object)

8. Performing heavy tasks in databound event

TRY TO AVOID

• Calling heavy tasks in each databound event
• Heavy tasks:
  • SQL calls,
  • Web service calls
• DataBound Event
  • RowDataBound in GridView
  • ItemDataBound in Repeater
• *Especially NO PAGING

WHY

It will be called N times, while N denotes page sizes

UNLESS

If your page size is relatively small. But still be careful!

PREFER

• Using custom data source to enable server side paging
• Generated from view (in you’re using EF)

9. Breaking the stack unnecessarily when you re-throw an exception

TRY TO AVOID

Breaking the stack trace unnecessarily when re-throwing exception with “throw ex”

WHY

• Losing the original stack trace
• It’s harder to trace back / debug which codes really causes error during production

UNLESS

You really expect the outcome

PREFER

• “throw”
• Wrapping up the exception with another exception while retaining the original as the inner exception

10. Storing clear-text password in config files

DO NOT

Storing clear-text password in config files

WHY

• Easy to get stolen
• Unauthorized access

DO

• Encryption
  • Consider the encryption with aspnet_regiis, example:

aspnet_regiis -pe "connectionStrings" -app "/SampleApplication"

• Combined with another mechanism such as certificate

Ok, I think we’re good to stop here today. Shall continue this again in the next post. See you!