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!
Pingback: ASP.NET Bad Practices: What you shouldn’t do in ASP.NET (Part 3) | Wely's Cloud Journey