Lately we've had a lot of custom web development projects where we are inheriting someone else's code, and we need to take over the project and make updates to it. It's been a bit crazy lately, and sometimes a bit frustrating. I just wanted to start keeping a log of things that other developers do that drive me crazy.
1. Having a method call another method when that's it's only purpose, and the other method isn't called from anywhere else. Something like:
public void RunCode() {
DoSomething();
}
public void DoSomething() {
int a=1;
int b=a+1;
..whatever...
}
If DoSomething() isn't called by anything else, what is it's purpose? Just put everything under RunCode(), no?
2. Making a database call on each row of a repeater (or datalist or gridview or whatever) Something like:
public void MyDataGrid_ItemDataBound(object sender, EventArgs e) {
Label lblFirstName = (Label)e.Item.FindControl("lblFirstName");
int userid = Convert.ToInt32(MyDataGrid.DataKeys[e.Item.ItemIndex]["userid"]);
Member oMember = new Member(userid);
lblFirstName.Text = oMember.FirstName;
}
This might look ok on the surface, but how are we populating the oMember object? We're making a database call right there in the constructor. This is not good practice because as the datagrid grows, every time it loads it will make a database call on every row. If you have many users hitting this page, your database activity could skyrocket unnecessarily. You should try to bind elements of your repeaters and datagrids to a single query that returns all the data you'll need to populate all of the fields, and don't make any database calls in repeating events.
3. SQL Cursors. Ugh, this is a real sore spot for me. I see so many developers using cursors, and 90% of the time, I am able to rewrite the query using a set-based query. I don't know why people use cursors so much. If you are writing a SQL cursor, you should just think it through and see if you can use a set-based query instead.
4. The Session object. This is perhaps the most widely abused object in all of web development. Every book I read about ASP.Net has at least a whole chapter devoted to the session object, its no wonder so many people use it. For one, using the session object causes the web server to have to allocate memory to EACH user who is using the website. When building web based applications, you want to minimize the amount of resources each user takes up on your web server so that you can grow without bringing the server down. People needlessly store variables in the session object so they can use them later instead of intelligently designing their application in such a way so as not to need the session object. On all of our web servers, we have the session object turned off right in the IIS settings and in 12 years I've never had the need to use the session object for anything.
