Windows Forms Standards

At work, we develop for both the web and for Windows. One of the things that we've had issues with over the years as developers come and go from our team, is keeping the Windows forms (written C#) consistent as far as usability goes. These are simple things to do, but sometimes hard to remember. I'm posting them here partly for me to remember and partly for others to maybe learn from. This list isn't meant to be exhaustive; just a few things seem to consistently pop up.

• Escape key should trigger the Cancel or Close button on the form. A lot people (me included) use the keyboard as much as possible, and this allows quickly closing the form you were using. To do this, just set the CancelButton property on the form to the ID of the appropriate button.
• If your form has an obvious default button, set that as well. This is done by setting the AcceptButton property. This allows the Enter key to trigger that button even when it doesn't have focus.
  
• Tab order should be set. Our internal standard is left to right, top to bottom on the form, unless otherwise specified by requirements. It doesn't matter what standard you use, as long as you have one and stick to it on every form you write. Visual Studio has a great visual way of doing this. With the form selected, click on View, then "Tab Order". This will put little numbers beside each form element. Just click on each element in the order you want them to be tabbed through. When you're done, the Escape key will exit out of this mode.
• Groupboxes should be used to separate functional areas on a form. For example, on a search form, the criteria would be in one groupbox, and the results grid would be in another. We use the Infragistics NetAdvantage suite, so we always use their UltraGroupBox control, but the standard Windows one works well too.
• Going back to keyboard usage: Menu items should have an accelerator key, where possible. To do this, just put an ampersand ("&") before the letter in the menu caption that you want to be the accelerator. This allows those of use who prefer using the keyboard to more quickly navigate around the application.
• Buttons on a form should also have accelerator keys when possible. This is done the same way it is for menus: just put “&” before the letter you want to be the accelerator. The “Cancel” button does not need this done, since it will always use Escape as its accelerator.
• For internationalization, we also always put field labels above the textbox or other control they refer to. This normally allows for more space to put in foreign languages, since they can end up being much longer than the original English equivalent.
  

Basics: Step Through New Code

One of the basic programming techniques that I try to use regularly is to step through any new code I write in the debugger. A lot of developers tend to only use the debugger for finding problems with code, but by the time you have a bug, I believe you've waited too long. Instead, as soon as you've written some new code, set a breakpoint at the start of it, and then run your application. When you hit the breakpoint, step through the code, asking yourself the following questions:

1. Is the flow correct for the conditions? That is, are all the conditional statements (if, while, for, etc) branching correctly based on the inputs? If not, why?
2. Are your variables getting set correctly? Watch the values of all local variables and parameters and make sure they match what you expected when you wrote the new code.
3. Are you able to make all (or almost all) branches of your code execute? Make sure you can hit all new lines of code, even if it takes several runs. There may be some error-handling or exception catching code that you may not be able to step into without some test code or other jumping through hoops, but do the best you can.
4. If it is a new method, does the return value match what you were expecting? Make sure you test all conditions possible.

I've found that I produce better quality code when I do this often. A lot of people recommend unit tests, and those are great when you can use them, but for some types of code, like UI code, they are either difficult or impossible to implement. Stepping through with a debugger is easy and doesn't take much more time than running your code normally. I've discovered errors or omissions quite a few times by doing this.

Welcome

I'm starting a blog to write about writing code. I'm a software developer, and I've been writing code since I was in high school (over 20 years ago!). I've been employed professionally as a software developer since 1992, and I've written code in C, C++, Perl, Visual Basic and C#, among others. I was inspired to start this by Jeff Atwood's recent post, where he encourages every developer to write a blog in order to improve their skills. Hopefully I will update this regularly and in the process learn something. You may learn something too.