I’ve so far covered 15 bad practices in the past three posts and I truly hope that all ASP.NET developers be aware of them including the consequences of each.
Today, I’ll be covering another 5 as the part four.
16. Style Properties on Controls
AVOID
- The four thousand specific control style properties, e.g.
- EditItemTemplate-AlternateItem-Font-ForeColor-Opacity-Level :S
WHY
- Maintainability
- Bigger page size resulting slower performance since it not being cached
PREFER
- CSS stylesheets
17. Filtering records on app level, not database level
TRY TO AVOID
- Bringing whole list of records from database and filter them on the application level
using (NorthwindEntities ent = new NorthwindEntities()) { var productList = ent.Products.ToList(); foreach (var product in productList) { if (product.UnitPrice > 1000) Export(product); } }
WHY
- Unnecessary traffic
- Unnecessary processing resource
DO
- Write proper query (or LINQ Query) to database
- Get only what you need
using (NorthwindEntities ent = new NorthwindEntities()) { var productList = ent.Products.Where(x => x.UnitPrice > 1000).ToList(); foreach (var product in productList) { Export(product); } }
18. Cookieless Form Auth & Session
DO NOT
- Enable cookieless forms authentication or session
WHY
- It could make your users being the victim to hijacking attacks
DO
- Enable “require cookies” for these features
- Consider using only secure (SSL) cookies for sites serving sensitive information
19. Missing “!IsPostback” check
DO NOT
- Forget the !IsPostBack check if you’re not expecting the execution on every postbacks.
- You can say that, this is so fundamental.
- Yes it is, but I’ve still seen quite couple of developers make this mistake!
protected void Page_Load(object sender, EventArgs e) { //initialize the code here }
WHY
- Overhead on the unnecessary calls might occurs
- Trigger incorrect / unexpected value
DO
- Understand what you’re really trying to achieve
- Put !IsPostBack check if you’re to only set the value for one first time.
protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { //initialize the code here } }
20. Putting Non-common scripts in MasterPages
DO NOT
- Putting unnecessary / non-common scripts / codes in masterpages
WHY
- All pages using the masterpages will be inherited the scripts
- Inappropriate usage may cause inefficiency
- Huge page size
DO
- Put only what really needed to be shared across child pages
- Consider using NestedMasterPages while part of scripts need to be inherited
That’s all for today’s 5 bad practices. Hope that I can compile some more and share with you again in future posts.
See you!