I can tell she is a born.... HUNGARIAN! (bravo, bravo, bravo!)

The title is for all you fans of My Fair Lady.

On to the actual topic: variable naming conventions.
http://www.joelonsoftware.com/articles/Wrong.html

Oh, wow. I really need to start following that blog!

(yes, I got totally distracted for about an hour. Check out this:
http://www.joelonsoftware.com/articles/fog0000000332.html)

(OK, make that 3 hours, and just subscribe to the above-mentioned blog. I did.)

Back to my original point: variable-naming.

When you get someone else's form, which you are meant to add code to, how do you know what (s)he named the controls? Let's say there are five textboxes, three radio buttons (in a single list), and two comboboxes (or drop-down lists, as you please).

Name ____________
Age ___
Weight ___ in O lbs O kilo O stone
Home town _____________
        State __|\/| (that's a combobox, OK?)
Favorite football team ___________|\/|
Favorite food ____________

Now then. I need to pull some data from the form (whether to validate it or for my own nefarious reasons). How do I know what the "Home town" textbox is called? What might it be?

I could go into the form and select the textbox, then look at the Properties box.

That means waiting:
1. wait for form designer to load (seconds)
2. wait for Properties box to load with my selected control (at least one more second)

Or I could make use of Intellisense by entering the first few characters of the control's name, with it prompting me with possible completions. This takes far less than a second... if the control's name is easily guessable.

If the textboxes have names like these:

UserName
Age
Weight
Units (for the list of options)

then Intellisense can only help me if I have a good guess of what my coworker had in mind. So is the control called City? Town? HomeTown? What about the combobox for the state? HomeState?

This is where Hungarian comes in. If you read the wiki on Hungarian notation, you'll find that this particular method of naming your variables has its detractors. Especially in the form I'm suggesting. More on that momentarily.

Hungarian notation means adding a prefix or suffix to your variable names (here, control names) indicating their type. Intellisense works with the first characters you type in, so I'm pushing for prefixes. Here are some Hungarian-named controls:

txtName
txtAge
txtWeight
radUnits

What does that do for me? If my team has been consistent about this, I don't care whose page I work on - I can get Intellisense to show me a list of all the controls of the desired type in three keystrokes (the first three characters of the variable name - that is, the prefix). Then I can choose from the descriptive remainder of the controls' names to get the actual value I want.

This form of Hungarian notation has been deprecated for being redundant - it doesn't add any information because the IDE already keeps track of variable types, and when you're writing a function the variables you want are either passed in as arguments or declared locally (as close to first use as possible, please, and no ten-page functions, and no global variables).

When we're dealing with a form on a designer, however, the story changes. Controls are not declared anywhere that is visible from the page of code you're working on; to view the original declaration, as mentioned above, takes more time than looking up or scrolling up. When you don't know the name of the control you want, only its type and the general meaning of its content or use, prefix Hungarian enables the use of Intellisense and makes life simpler and easier.

More Asynchronous Stuff

We've divided up the project, and I have selected a new (and exciting?) role for myself: the UI developer. Web UI, that is.

Taking a look around at popular sites, I can tell you already that I need to learn all about making good use of AJAX. Let me attempt to define it, based of course on an acquaintance of less that three weeks.

Traditional ASP and ASP.NET sites are heavy on the server-side processing. For any event you want to handle, the page needs to post back to the server and be loaded again. If your page is large, that's a lot of work. There are ways to pare down on page size (by making only the necessary controls ViewStateEnabled, for one thing), but the bottom line is a page reload for every click of a button. This means slow loading, flickering, and a choppy user experience.

Popular sites are developed by people who know what their audience wants. And while I am not yet a developer of a popular site, I can tell you right now what my audience wants: a site that loads quickly and that doesn't flicker. (Or hang up. Or crash their browser. More on those in a minute.)

Enter AJAX, a technology that was available as an add-in in Visual Studio 2005 and is a charter member of Visual Studio 2008. With AJAX, you can integrate Javascript asynchronous event handling into your page. The Javascript handlers asynchronously call server-side functions (exposed via .asmx web service or WCF - and one other method, for another post). The user continues interacting with a living, breathing page while the Javascript's spare thread waits for a response from the server; when the response arrives, the main thread updates the page accordingly and all is well. Mostly.

Note that I said the handlers asynchronously call server-side functions. The call is asynchronous; the server-side functions are not necessarily. What does this mean to my end-user? What does this mean to me?

The trouble comes in when the server response takes a long time. If many requests come in, and enough of them are taking a long time, then my server will run out of threads and my site will hang up. (Remember what I said? My users won't want that.)

The solution, my friends, is easier said than done: implement asynchronous calls where appropriate on the server side. For example, if my service function is doing I/O with the data store, the call to the DAL should be asynchronous. That way, the thread working on that service call can sleep instead of "busy waiting" and free itself up for another service call (maybe one that doesn't need any heavy I/O).

Sounds great in theory. What about in practice?

I think I'll go practice...