10 Mistakes every .Net Developer Would Regret

Admit it! We all make mistakes. None of our codes starts working at strike one. We make typos, forget signing off or, as it happens with most of us, overlook the testing phase, especially when it comes to ASP.net development. To err is human. So, making mistakes is just another human phenomenon. What counts is how you tackle your errors and how you devise ways to avoid them in the ventures to come. Here’s a compilation of some of the most common testing mistakes that developers often commit while catering to outsource .Net development needs. Let’s take a look. XSS Security Issues: The look and feel of your UI and of course, its maintenance lies in your hands. Ensure that all user-input fields are well-customized so that no JavaScript or HTML that a user enters can rummage your web page. Universal Localization: As a usual norm, as you begin developing a new feature, you keep all the text in hard code as there are probabilities of certain changes during the course of development. As soon as the project team approves the feature, you localize the text. However, at times you tend to forget localizations of the entire text. You remember to hard code, but when it comes to localization you tend to sign off without doing the same. Probably this checklist reminds us to localize before we sign off the next time. .Net Behaves Well with IE 6 and 7 and Firefox: Test leads often report of cross-browser compatibility issues that crop up from time to time. Most of these issues usually encompass small twigs like usual IE 6 issues or minor problems relating to positioning of elements. We are dedicatedly focusing on IE version 6 and 7 and Mozilla Firefox for two reasons. Firstly, if your web page works well in these three browsers, it will function well on Opera and Safari as well. Secondly, over 98% of the visitors access your site through these browsers. Reuse Code as and when required: This law is applicable across all programming platforms and ASP.Net is no exception. Separate server and user-control elements enable specialization of code so that it can be used at other places as well. Commenting on the Code: There are no two-ways to this. Always document your code well and comment upon the right places, so that it is easier for other developers to pick up from where you left. Extended Text doesn’t Mean Broken Design: As a matter of fact, names usually don’t extend beyond 50 characters, but what if some user inputs a name containing 300 or even more characters. Obviously, in that case the UI will be disrupted. In this case you have two options- either codes your interface to accept long text inputs or put a limit on the length of text users can input. Write Units When Possible: Unit testing for your website can be a tedious job especially if you are not using ASP.Net MVC framework for the same. However, pulling the code-behind logic into different components that can be placed in the library can enable you to test the units. Instead of dealing with HttpHandlers using .ashx files, placing them in separate libraries is a good option. Peer Verification before Testing: Before signing off any newly added feature and sending it across to the test team, you usually pass it through peer verification. As the name suggests, in peer verification, one of your colleagues tests the application feature you have just developed and tries to find flaws in it. This allows you to identify errors easily and also simplifies the process for the testing team. When schedules are really tight, we often forget to ask for peer verification and it definitely shows at the end. Expected functioning of Enter-key: When you are using webforms in ASP.Net, the enter-key often starts functioning weirdly. In this case, you can either set default buttons on the Panel webcontrol or from code-behind. Sign Off by Product Owner: By default, the ownership of a product feature lies with the product team. Developers also have a share in ownership but that is only until the implementation level. Often when you have too much to handle, you forget to get a sign off from product owner. If the owner doesn’t sign off your work it means you haven’t completed it, even if you have already marked it as done. rnThis is frustrating and can extend deadlines. The aforementioned mistakes are common and can be made by any developer. If you are an Asp.net developer, these mistakes should be taken care of in the next development venture. If you are a business owner and looking to hire .net developers, then ensure that your developers take care of the same while developing your web application.