Brendan Enrick

Daily Software Development

Using Fiddler with Mozilla Firefox

Earlier today I read a very interesting blog post from Steve Smith. I use FireBug for all of my debugging purposes in Firefox. I wish that IE had a tool as amazing as FireBug. Sadly, I know of none. I had a similar desire for Firefox, because I use Fiddler with IE. That I knew of it wasn't possible to use Fiddler with Firefox. That always annoyed me, because Fiddler is a powerful tool for analyzing HTTP traffic.

It seems Steve was under the same impression as I was. Luckily someone pointed out to him that Firefox can be manually configured to work with Fiddler. Check out Steve's blog post where he details how to configure Firefox to use Fiddler. Steve has some screen shots and details the steps pretty well.

Thank Steve for posting this!
Thank Ivo Evtimov for telling Steve about it!

ASP.NET MVC Beta Released

Just in case you missed the blog post from Scott Guthrie yesterday, I will post this.

Scott Guthrie's MVC Beta Announcement

ASP.NET MVC Beta Download

One of my favorite little added bonuses of using IDEs is that I get a lot of helpers that generate code and files for me. If I call a method that doesn't exist I am able to have a stub of the method automatically generated. In the ASP.NET MVC beta they've added a new menu for adding views.

The Add View window it brings looks extremely useful. I look forward to using that to create my views. It handles strongly-typed views and MasterPage selection.

Overall it looks like a nice release.

For those of you who want to deploy using ASP.NET MVC keep in mind that Scott says this in his post.

Today's ASP.NET MVC Beta release comes with an explicit "go-live" license that allows you to deploy it in production environments.  The previous preview releases also allowed go-live deployments, but did so by not denying permission to deploy as opposed to explicitly granting it (which was a common source of confusion).  Today's release is clearer about this in the license.

Good day and enjoy ASP.NET MVC's newest release.

Defining Progress in Software Development

One thing I probably say too often when working on code with other people is, "That's a new error. We're making progress." I take a bit of crap from a coworker of mine because of this. He thinks it is quite funny that new error messages are what I consider to be progress. After tracking down a bug creating some exception, it is nice to get a different message. This is of course as long as the newly written code didn't create the new error message. The idea when I say this is that I have removed a roadblock and gotten to the next one.

Perhaps we can make some analogy here about a hurdle runner jumping over a hurdle only to get to another one. Someone might say that it is bad that he is at another hurdle, but I prefer to say that it is great because he has made progress and is closer to reaching the finish line. Maybe he has one hurdle left, maybe twenty. It doesn't matter really as long as he is closer to the goal.

So leave me alone about the new error message thing being progress..... Ed.

A Note on ASP.NET Session

A while back, I was asked a question by one of the junior developers here at Lake Quincy Media. I had him working on a little feature on an ASP.NET site which could be easily handled using Session. "Where is session stored, on the server or the client?" he asked. As a quick response I said that it's stored on the server. He followed that by saying, "So it doesn't use a cookie?"

And that was all it took to set me on one of my usual lengthy explanations of how a piece of functionality actually works.

How is ASP.NET Session stored?

In ASP.NET, session data is stored on the server. It is stored in a per-user basis and maintained only for a limited period of time. Anyone who has used sessions knows that it is accessed during server-side code execution and is accessed using strings as keys. So we know that Session data is stored as key-value pairs. The following is basically how we access the session information. In this code I store a string in Session and pull it back out from session.

string name = "Brendan Enrick";
Session["fullName"] = name;
string nameFromSession = Session["fullName"] as string;

Pretty simple really. It is a nice way to store data for a user during this visit to the site.

How are users associated with their session?

In the default scenario for ASP.NET Session, cookies are used. No, the data is not stored in the cookie. When a Session is started on the site, the user is given a cookie (yummy cookie) which contains a unique identifier for accessing the session. While the user navigates around the site, the browser sends the cookie information to the server. This is what keeps the user associated with his session. Each time the server receives the cookie from the user so when your code requests data from session, it is pulling the data from the session associated with that user.

Can cookies be avoided?

Yes, it is possible to avoid using cookies. Session is able to run without cookies by setting a boolean property in the web.config file to true. The property is called cookieless and it is on sessionState. When session is not using cookies it instead places the SessionId in the url the user requests. Internal links on the site contain the unique session id so that the processing which occurs on the server is able to access the correct session values. I prefer not using this method because it just makes URLs all over the site look terrible.

How long are values saved in session?

By default the timeout for session in ASP.NET is 20 minutes. This means that the session will expire 20 minutes after the user last accessed the site, so as long as the user continues using the site it will not expire. If the user waits 25 minutes before clicking a link, the session will have expired. It is easy to adjust the length of time before sessions expire. In the web configuration file you can simply adjust the value for timeout on the sessionState element.

<sessionState cookieless="false" timeout="45" />

And this is why asking me questions can be a bit crazy. I'll first go on a lecture about the topic and then eventually I'll publish a blog post so I don't have to lecture again. Now if someone asks me that question I'll send him here.

Separation of Concerns

Continuing on my previous post about separation of code responsibilities where I was mostly just discussing one aspect of a book I appreciate, I now want to comment on the concept of separation of concerns. While thinking about this idea I realized that I've been a follower of this idea longer than I previously thought. I admit it, I don't separate my code as well as I often could.  I am sure that everyone reading this has heard that we should try to make things modular and that we should encapsulate pieces of our code. It is all part of what I consider to be classical education taught to programmers everywhere.

Separation helps for many reasons. It allows us to think about only the currently important section of code. We need not always be concerned with how everything else works. It is much easier to solve problems by implementing a solution that doesn't require at every step being concerned with the details. If I want to tell someone how to load boxes into a truck. I want to say something like this.

  1. Pick up a box
  2. Place the box in the bed of the truck
  3. Repeat previous steps until no boxes remain outside the truck

I don't want to have to do something like this.

  1. Pick up a box
    1. Move next to a box
    2. Bend knees so you're at about the same level as the box
    3. Put hands on the box
    4. Grip the box tightly
    5. Lift up using your knees
  2. Place the box in the bed of the truck
    1. Move while still gripping the box
    2. Walk over to the back of the truck
    3. Move box away from body and toward the truck
    4. Let bottom of box touch the truck bed
    5. Release grip on the box
    6. Move hands away from the box
  3. Repeat previous steps until no boxes remain outside the truck

I prefer to be able to assume that the person I am talking to knows the simple things. If I have to get into this kind of detail anytime I tell someone how to do something I am going to forget details along the way. I'm going to say something incorrectly. I also may mess up the overall algorithm because I am too concerned with the details of the steps. With different pieces being separated it makes it much easier to solve problems. There are plenty of other reasons to separate what we create.

SeparationOfConcernsAnother reason that it is nice to have our work separate out nicely is that we are able to replace and adjust sections of our work without having to rip it all apart. If I have been having sections of code performing plenty of different tasks then I make it a lot harder to change it. When I go to make a change I am dealing with a lot more than I need to be, because a lot more stuff is there. The benefits of this are plenty and I am sure people can suggest plenty more. (I am also sure there are plenty of reasons to not have modular code.)

As I am sure is the case for many developers reading this, I spent a lot of time working with Linux machines. One thing I of course noticed with the classic applications found in the open source world is the tendency to have individual programs perform one task. The output of one program is often passed as input into the next program.

One line I heard often is, "Why does program xyz need to sort its output? Just send it through program abc, because it sorts already." At first I think the idea of having a program for sorting is kind of silly. Isn't it easy to sort? Couldn't all of these programs just sort? Well even sorting text can be fairly complicated. Which algorithm should you use? Should sorting be on the first character or the second? Maybe we want to sort based on the second column of data. I don't want to go into the code for a large number of programs just to update how it sorts.

Along with separation of concerns comes the also very important need to break dependencies. When we perform this separation we are breaking things into separate objects, libraries, and who knows what else. Some dependencies aren't a big deal. Most of my applications are fairly dependent on the .NET Framework, but I am not concerned with this. If I am stopping using the .NET Framework, I am probably switching languages or something and rewriting anyway.

While thinking about how to break up responsibilities among sections of code I've really been noticing how great an idea those separate programs have always been in the Linux world. I've noticed a trend away from it, but the core applications still tend to follow that old principle. Keep things small and performing only one task. Need something else? Let another program handle that task. As any code attempts to do more, it just becomes more difficult to work with.

The idealistic purpose of computers is to make our lives easier. Try not to let them do the opposite.

Separation of Code Responsibilities

One book I would highly recommend reading is Working Effectively with Legacy Code.  I should write a review of this book at some point, but for now I just want to mention one great thing about it. Reading the book is very valuable, but it is an excellent reference book. Many of the chapters of the book are devoted to certain scenarios which might arise when dealing with legacy code. It then goes on to explain how to handle these situations.

At the moment I am attempting to change some code which needs to make a bunch of API calls. Right now the code is not neatly written and methods are directly interacting with the API, performing in-memory work, and calling methods to save data. Since I am relatively new to this stuff, I figured I'd read the chapter titled, "My Application Is All API Calls".

In the chapter, the author uses a simple example about a mailing list server. The application is a big jumbled up mess. As the text preempting the code states, "We're not even sure it works". This type of situation is exactly what I am trying to avoid, and a great way to know something works is to have tests written for it which demonstrate the code's ability to function correctly. The tests are also a great way to show what a piece of code does.

When the author is discussing how to design the application in a better way, he mentions his desire to separate the code's responsibilities. Now I know that separating code responsibilities is important, but his example really shows it well I think.

1. We need something that can receive each incoming message and feed it into our system.

2. We need something that can just send out a mail message.

3. We need something that can make new messages for each incoming message, based on our roster of list recipients.

4. We need something that sleeps most of the time but wakes up periodically to see if there is more mail.

The nice thing is it then becomes so much easier to work with the API calls because they've so nicely been separated. One mistake I've made in the past is not separating out the code which needs to periodically perform some other action. I have attempted in the past to link that together with the code performing the local work. BIG MISTAKE!

Right now what I am planning on writing is going to have these separate responsibilities:

  1. Something to fetch data from an external source.
  2. Something to manipulate the retrieved data into its desired format.
  3. Something to store the data internally.
  4. Something to periodically check for new data.

Notice the incredible similarity there. It is very nice for my application, because only one piece needs to know about the API, and only one piece needs to know how the data is stored. Instead of before where some of that was a bit muddled together. This separation keeps the code cleaner and much easier to code. Testing will also be a lot easier because of this separation.

One of the most difficult parts about testing code well, is that lots of code is not separated well enough to be tested. Being too tightly connected to an API makes code nearly impossible to test, so it is hard to tell if a piece of code is working or what it does.

Dependency Injection Frameworks

Lately I've been taking a look at dependency injection, and I've spent a little bit of time examining Ninject. I've read most of the Ninject Documentation, and so far I'm very interested in it. I love that it doesn't depend on configuration files. The "modules" it uses look very interesting. Whenever possible I prefer to use strongly typed everything. I love the compiler and everything it can do for me. I also love intellisense, and not depending on config files helps me to use both of those.

I've heard a little bit about some other dependency injection frameworks including Windsor and StructureMap. Not really sure what people are using. I'm pretty well sold on Ninject for now, so if anyone has any opinions or information I need to consider please let me know. I would be glad to hear what other people are using and what their opinions are.

Dependency injection makes a lot of sense, but with a few different choices out there, it is hard to say which route someone should take. I also like the fact that ninject seems to be a lot lighter weight than some other frameworks. In general I prefer add-ins which have very small footprints. If there is one thing I can't stand it is code that dominates everything else.

Nested Using Statements

I think it is a great idea to always be reading code. You may learn more than you intend to sometimes. Read an article to learn one trick and you may learn a completely different one. Earlier today I was reading some code written by Steve Smith. He wrote an extension method for the System.Web.UI.Control class called RenderControl. I was just looking to see what he had written, and from this little snippet of code I learned a cool trick.

 

public static string RenderControl(this System.Web.UI.Control control)
{
    StringBuilder sb = new StringBuilder();
    using (StringWriter sw = new StringWriter(sb))
    using (HtmlTextWriter textWriter = new HtmlTextWriter(sw))
    {
        control.RenderControl(textWriter);
    }
    return sb.ToString();
}

In the past I would have nested my using statements like this.

public static string RenderControl(this System.Web.UI.Control control)
{
    StringBuilder sb = new StringBuilder();
    using (StringWriter sw = new StringWriter(sb))
    {
        using (HtmlTextWriter textWriter = new HtmlTextWriter(sw))
        {
            control.RenderControl(textWriter);
        }
    }
    return sb.ToString();
}
So now I can go ahead and save myself some curly braces and extra indentation.

I enjoy all the little things one can learn from reader the code others write.

Using a DropDownList without ViewState

One of the most ViewState heavy controls is the DropDownList. It stores in ViewState the Text and Value for every ListItem in the DropDownList. This means large Lists can get really nasty when ViewState comes into play. They also include all of these entries a second time because they're all in the html. Being in the html will only slow the page down as it is sent to the user, but the ViewState is downloaded by the user and also must be uploaded back up to the web server. This is a horrible user experience if the page has a large amount of ViewState. Since upload speeds are usually worse than download, the user will probably not like the amount of time the postbacks on the site take. In the following example I am going to show how much ViewState can be saved by simply reloading the data into the DropDownList each time the page is requested.

This is how much ViewState my hundred item DropDownList contains at the beginning of this example.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwNjkzMDQ2Nz
MPZBYCAgMPZBYEAgEPEA8WAh4LXyFEYXRhQm91bmRnZBAVZAlFbGVtZW50IDAJRWxlbWVudCAxCUVsZW1lbnQg
MglFbGVtZW50IDMJRWxlbWVudCA0CUVsZW1lbnQgNQlFbGVtZW50IDYJRWxlbWVudCA3CUVsZW1lbnQgOAlFbG
VtZW50IDkKRWxlbWVudCAxMApFbGVtZW50IDExCkVsZW1lbnQgMTIKRWxlbWVudCAxMwpFbGVtZW50IDE0CkVs
ZW1lbnQgMTUKRWxlbWVudCAxNgpFbGVtZW50IDE3CkVsZW1lbnQgMTgKRWxlbWVudCAxOQpFbGVtZW50IDIwCk
VsZW1lbnQgMjEKRWxlbWVudCAyMgpFbGVtZW50IDIzCkVsZW1lbnQgMjQKRWxlbWVudCAyNQpFbGVtZW50IDI2
CkVsZW1lbnQgMjcKRWxlbWVudCAyOApFbGVtZW50IDI5CkVsZW1lbnQgMzAKRWxlbWVudCAzMQpFbGVtZW50ID
MyCkVsZW1lbnQgMzMKRWxlbWVudCAzNApFbGVtZW50IDM1CkVsZW1lbnQgMzYKRWxlbWVudCAzNwpFbGVtZW50
IDM4CkVsZW1lbnQgMzkKRWxlbWVudCA0MApFbGVtZW50IDQxCkVsZW1lbnQgNDIKRWxlbWVudCA0MwpFbGVtZW
50IDQ0CkVsZW1lbnQgNDUKRWxlbWVudCA0NgpFbGVtZW50IDQ3CkVsZW1lbnQgNDgKRWxlbWVudCA0OQpFbGVt
ZW50IDUwCkVsZW1lbnQgNTEKRWxlbWVudCA1MgpFbGVtZW50IDUzCkVsZW1lbnQgNTQKRWxlbWVudCA1NQpFbG
VtZW50IDU2CkVsZW1lbnQgNTcKRWxlbWVudCA1OApFbGVtZW50IDU5CkVsZW1lbnQgNjAKRWxlbWVudCA2MQpF
bGVtZW50IDYyCkVsZW1lbnQgNjMKRWxlbWVudCA2NApFbGVtZW50IDY1CkVsZW1lbnQgNjYKRWxlbWVudCA2Nw
pFbGVtZW50IDY4CkVsZW1lbnQgNjkKRWxlbWVudCA3MApFbGVtZW50IDcxCkVsZW1lbnQgNzIKRWxlbWVudCA3
MwpFbGVtZW50IDc0CkVsZW1lbnQgNzUKRWxlbWVudCA3NgpFbGVtZW50IDc3CkVsZW1lbnQgNzgKRWxlbWVudC
A3OQpFbGVtZW50IDgwCkVsZW1lbnQgODEKRWxlbWVudCA4MgpFbGVtZW50IDgzCkVsZW1lbnQgODQKRWxlbWVu
dCA4NQpFbGVtZW50IDg2CkVsZW1lbnQgODcKRWxlbWVudCA4OApFbGVtZW50IDg5CkVsZW1lbnQgOTAKRWxlbW
VudCA5MQpFbGVtZW50IDkyCkVsZW1lbnQgOTMKRWxlbWVudCA5NApFbGVtZW50IDk1CkVsZW1lbnQgOTYKRWxl
bWVudCA5NwpFbGVtZW50IDk4CkVsZW1lbnQgOTkVZAlFbGVtZW50IDAJRWxlbWVudCAxCUVsZW1lbnQgMglFbG
VtZW50IDMJRWxlbWVudCA0CUVsZW1lbnQgNQlFbGVtZW50IDYJRWxlbWVudCA3CUVsZW1lbnQgOAlFbGVtZW50
IDkKRWxlbWVudCAxMApFbGVtZW50IDExCkVsZW1lbnQgMTIKRWxlbWVudCAxMwpFbGVtZW50IDE0CkVsZW1lbn
QgMTUKRWxlbWVudCAxNgpFbGVtZW50IDE3CkVsZW1lbnQgMTgKRWxlbWVudCAxOQpFbGVtZW50IDIwCkVsZW1l
bnQgMjEKRWxlbWVudCAyMgpFbGVtZW50IDIzCkVsZW1lbnQgMjQKRWxlbWVudCAyNQpFbGVtZW50IDI2CkVsZW
1lbnQgMjcKRWxlbWVudCAyOApFbGVtZW50IDI5CkVsZW1lbnQgMzAKRWxlbWVudCAzMQpFbGVtZW50IDMyCkVs
ZW1lbnQgMzMKRWxlbWVudCAzNApFbGVtZW50IDM1CkVsZW1lbnQgMzYKRWxlbWVudCAzNwpFbGVtZW50IDM4Ck
VsZW1lbnQgMzkKRWxlbWVudCA0MApFbGVtZW50IDQxCkVsZW1lbnQgNDIKRWxlbWVudCA0MwpFbGVtZW50IDQ0
CkVsZW1lbnQgNDUKRWxlbWVudCA0NgpFbGVtZW50IDQ3CkVsZW1lbnQgNDgKRWxlbWVudCA0OQpFbGVtZW50ID
UwCkVsZW1lbnQgNTEKRWxlbWVudCA1MgpFbGVtZW50IDUzCkVsZW1lbnQgNTQKRWxlbWVudCA1NQpFbGVtZW50
IDU2CkVsZW1lbnQgNTcKRWxlbWVudCA1OApFbGVtZW50IDU5CkVsZW1lbnQgNjAKRWxlbWVudCA2MQpFbGVtZW
50IDYyCkVsZW1lbnQgNjMKRWxlbWVudCA2NApFbGVtZW50IDY1CkVsZW1lbnQgNjYKRWxlbWVudCA2NwpFbGVt
ZW50IDY4CkVsZW1lbnQgNjkKRWxlbWVudCA3MApFbGVtZW50IDcxCkVsZW1lbnQgNzIKRWxlbWVudCA3MwpFbG
VtZW50IDc0CkVsZW1lbnQgNzUKRWxlbWVudCA3NgpFbGVtZW50IDc3CkVsZW1lbnQgNzgKRWxlbWVudCA3OQpF
bGVtZW50IDgwCkVsZW1lbnQgODEKRWxlbWVudCA4MgpFbGVtZW50IDgzCkVsZW1lbnQgODQKRWxlbWVudCA4NQ
pFbGVtZW50IDg2CkVsZW1lbnQgODcKRWxlbWVudCA4OApFbGVtZW50IDg5CkVsZW1lbnQgOTAKRWxlbWVudCA5
MQpFbGVtZW50IDkyCkVsZW1lbnQgOTMKRWxlbWVudCA5NApFbGVtZW50IDk1CkVsZW1lbnQgOTYKRWxlbWVudC
A5NwpFbGVtZW50IDk4CkVsZW1lbnQgOTkUKwNkZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dn
Z2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2
RkAgUPDxYCHgRUZXh0BQlFbGVtZW50IDBkZGQCc/YoLQgXzJamhzzCRizwdOQs9w==" />

And at the end of it, this is all that remains.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwNjkzMDQ2NzM
PZBYCAgMPZBYCAgUPDxYCHgRUZXh0BQpFbGVtZW50IDIzZGRky26p9Cn4TiZyx2yoBv7mRgWW+gQ=" />

It is a frightening thought, but there are plenty of sites with far more ViewState than this. I am talking some people have talked to me about pages that are multiple megabytes in size.

In the following example I use a simple page with 1 DropDownList, 1 Button, and 1 Label.

Here is the starting Default.aspx page.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" EnableViewState="true" />
        <asp:Button ID="Button1" runat="server" Text="Postback" />
        <asp:Label ID="Label1" runat="server" />
    </div>
    </form>
</body>
</html>

Here is the starting Default.aspx.cs code-behind file.

using System;
using System.Web.UI.WebControls;

public partial class _Default : System.Web.UI.Page 
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            // Create my data source (this would normally be data access or something similar)
            System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
            for (int i = 0; i < 100; i++)
            {
                myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
            }
            DropDownList1.DataSource = myData;
            DropDownList1.DataBind();
        }
        else
        {
            Label1.Text = DropDownList1.SelectedValue;
        }
    }
}

Now we can make a little change here. We need to disable ViewState. The other change that we need to make is that we now have to populate the data on every request. We also need to make sure that we populate the DropDownList before Initialization of the Page occurs. This means we should override OnInit and place out code before base.OnInit. The reason we do this is so that we have data loaded in the DropDownList before the selected value of controls are set for us. Otherwise we would have to handle this on our own.

This is the new Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:DropDownList ID="DropDownList1" runat="server" EnableViewState="false" />
        <asp:Button ID="Button1" runat="server" Text="Postback" />
        <asp:Label ID="Label1" runat="server" />
    </div>
    </form>
</body>
</html>

This is the new Default.aspx.cs

using System;
using System.Web.UI.WebControls;

public partial class _Default : System.Web.UI.Page 
{
    protected override void OnInit(EventArgs e)
    {
        // Create my data source (this would normally be data access or something similar)
        System.Collections.Generic.List<ListItem> myData = new System.Collections.Generic.List<ListItem>();
        for (int i = 0; i < 100; i++)
        {
            myData.Add(new ListItem("Element " + i.ToString(), i.ToString()));
        }
        DropDownList1.DataSource = myData;
        DropDownList1.DataBind();
        base.OnInit(e);
    }

    protected void Page_Load(object sender, EventArgs e)
    {
        if (IsPostBack)
        {
            Label1.Text = DropDownList1.SelectedValue;
        }
    }
}

Enjoy not having TONS of extra ViewState. Remember that ViewState is extremely useful, but can cause problems if you ignore its existence completely. It can lead to huge pages that are quite slow.

Long Code Lines in Articles and Tutorials

While publishing articles for ASP Alliance I often take the time to fix long code lines I find in the articles. These bother me greatly, because they make web pages and thus the article ugly and difficult to read. I hate having to scroll horizontally to read a long line of code. It is annoying and takes more time. I don't get why people don't trim their code. I keep my code neatly trimmed when I'm writing articles, and also whenever it is code I am writing in general. I never want code lines to be too long. I have no problem scrolling vertically, but there should be some set limits on how long lines should ever be especially when the lines will be posted on the Internet.

Some of the ugliest sites I've ever seen are the ones where text has gotten too wide and has taken over the layout of a page. Widths have been stretched and the page extends beyond its intended positioning. I admit this has happened plenty of times on sites with which I am associated and I am ashamed. It would be nice if I could convince the rest of the development community of the importance of having code be easy to read. How can I possibly intend to help other people understand something through an article or tutorial when my code is difficult to read. I'm not helping their understanding at all by having them struggle to read the code let alone understand it.

I think overall the software development community could use a facelift. My site included. Sadly my skills in the area of design are quite lacking. Formatting text in a readable manner is about the extent of my skills, but I believe that is likely the most important task to complete.

Get rid of lines like this one.

MyCompany.Controls.DropDownList commentselectionddl = SomeTemplatedControlOnThePage.FindControl("commentselectionddl") as MyCompany.Controls.DropDownList;

Replace them with lines like this one.

MyCompany.Controls.DropDownList commentselectionddl = 
    SomeTemplatedControlOnThePage.FindControl("commentselectionddl") as MyCompany.Controls.DropDownList;

For the benefit of everyone involved in this wonderful community of developers, format your code. Make it more readable. Don't let lines trail off into the distance. Keep them short and concise. Use simple examples, and never make code more complicated just to show how smart you are. I've seen plenty of code where authors attempt to complicate their own code seemingly to make themselves appear smarter. Remember, when you write code you should not be writing for yourself. Write the code for someone else to learn. Write to help other people and make the community as a whole a better place. Sure it benefits you when you teach others, but remember that at the end of the day other people will be reading what you write.