Month: September 2006

I’ve recently been building quite a few VPC images for betas, testing, sandboxing etc and have made use of the techniques that Jeff Atwood posted about and I linked to in a previous post. It’s staggering how small you can make them, and how much faster they load. Jeff’s article is essential reading if you are making use or intending to make use of VPC’s. I managed to get a full Windows XP Sevice Pack 2 image down to 584MB !

I was doing a spot of late night browsing (in fact I was in the middle of reading a very interesting article on Agile development experiences when the server went down!), and came across a totally unconnected MSDN article from July 2001, which is a beauty. Creating Windows XP Icons describes in step-by-step detail how to create icons just like the guys at Microsoft. It describes the palette, perspective, common icons for toolbars, adding drop shadows, creating correct transparency maps etc.

If you are a designer or a programmer in a designer’s shoes, this is a must read. The article has been rated over 7500 times and it has an average rating of 8 out of 9 (who’s the person that seems to visit every MSDN article and give a rating of 1 ?!?)

If you use the Visual Studio IDE frequently there are a number of shortcuts that can make you more productive. None of these tips are new, but there might be one or two shortcuts you were not aware of. The majority of these tips come directly from the Tech-Ed 2005 and 2006 presentations given by Anson Horton and Karen Liu respectively. I’ve condensed the gist of these 1 hour sessions into what you see here. [Note: these are the C# key bindings; other languages may differ]. One thing certainly worth remembering is that adding the Shift key to most key combinations causes the opposite sense of whatever the action is.

These useful shortcuts come under the following headings:

• Understanding code
• Navigating code
• Modifying code
• Debugging code

Understanding Code: Exploring the .NET framework’s Class Relationships

The dynamic class diagram is a great way of exploring class relationships in ­­the .NET framework. Now I’m sure most people will already be using the class diagram for their own class hierarchies (Add a class diagram, go to class view [Ctrl-W, Ctrl-C], and drag a class to the diagram), but did you know that you can also use a class diagram as a great way of getting familiar with the .NET framework in VS2005? In class view, open the “Project References” tree and drag a namespace to the class diagram (e.g. System.IO). Also, don’t forget you can “Show Derived classes” by right-clicking on a class.

Navigating Code

You are probably aware of the right-click ‘Go to Definition” navigation (with your cursor placed in a symbol). It is also bound to F12. What you might not be aware of is its counterpart, Shift-F12 which shows all references to the symbol defined at the current cursor location.

F12 – Go to symbol definition
Shift-F12 – Show all references to a symbol

The F8 key is a great shortcut key to remember. It can cycle through all references found with F12, and in addition it can cycle through any ‘List’ output window, such as the task list, error list, etc.

F8 – Cycle through list of items in the currently active output window
Shift-F8 – Same as F8 but in the opposite direction

The next two key ‘chords’ are very useful when you are dealing with unfamiliar code, as they provide a high level view of a class’s methods:

Ctrl-M, Ctrl-O – Collapses all methods to outline view
Ctrl-M, Ctrl-M – Collapses/expands the method the cursor is currently in.

Most people are aware of the “IE style navigation” using Ctrl-minus and Ctrl-Shift-minus to move backwards and forwards through visited code:

Ctrl-‘-‘ – Move backwards to previous cursor location
Ctrl-Shift-‘-‘ – Move forwards to last cursor location

But the following two are less well known (and in many instances, more useful). If you are navigating a sequence of method calls, and you move around in the surrounding code, the IE style navigation will cycle through every location the cursor was placed. The following two commands move up and down the “Definition Navigation Stack”, so just those methods that you delved into using F12:

Ctrl-Shift-8 – Move up the definition navigation stack (stack pop)
Ctrl-Shift-7 – Move down the definition navigation stack (stack push)

Another less known shortcut is Ctrl-I which activates incremental search. Open a source file, hit Ctrl-I and start typing the first few letters of your search text. Visual Studio will go to the first occurrence and continuing searching as you enter more characters. Hit Ctrl-I to go to the next occurrence (and of course, Ctrl-Shift-I to go to the previous). Pressing Escape will turn off incremental search.

Ctrl-Shift-I – Incremental search
Ctrl-Shift-F – Find in all files (more useful than Ctrl-F)
Ctrl-H – Replace

Another tip involves finding files. You can download a free add-in called VS File Finder from the following link: http://www.zero-one-zero.com/vs. It’s easy to use and good for navigating in large solutions. File Finder shows up as a new window after you install it from the .msi file. I docked mine with the output and list panels at the bottom of the IDE window. Any text you enter in the textbox will filter the list of files displayed by partial file name matches. [From Visual Studio Hacks, by James Avery.]

For some reason, I always seem to forget these two shortcuts:

F7 – Switch to code view
Shift-F7 – Switch to design view

Modifying Code

Ctrl-K, Ctrl-C – Comment out currently selected code
Ctrl-K, Ctrl-U – Uncomment currently selected code
Ctrl-K, Ctrl-F – Auto format selected code

FxCop is a Static Analysis tool that can not only help you come to terms with an unfamiliar code base (see previous post) but also to improve existing code. FxCop runs over the IL generated from your source code and performs a set of rule based comparisons on it. There are 2 rule sets that can help with refactoring: naming and maintainability. One of the rules that can generate warnings relates to something called ‘cyclomatic complexity’. Cyclomatic complexity is just the number of branches in a method. The higher the value, the greater the likelihood that a method could be reduced by having sections of code extracted into new methods (refactored).

Visual Studio 2005 contains a number of refactoring commands to help you reorganise code:

Ctrl-R, Ctrl-M – Extract method
Ctrl-R, Ctrl-E – Encapsulate field
Ctrl-R, Ctrl-I – Extract Interface
F2 – Rename

[Ctrl-R is the first ‘note’ in most refactoring key combinations, and there are other refactoring commands in addition to those I’ve listed above]

Debugging Code

These are essential debugging shortcuts:

F10 – Step over
Ctrl-F10 – Run to cursor
F11 – Step into
Shift-F11 – Step out
F9 – Toggle a breakpoint
F5 – Run with debugging
Shift-F5 – Stop debugging
Control-F5 – Run without debugging

Attributes can make your debugging more effective by declaratively altering the behaviour of the debugger:

[DebuggerStepThrough()] is used to decorate a method or property to prevent the debugger stepping into it whilst debugging.

[DebuggerDisplay(“{propertyname}”)] allows you to define the value which is displayed by default in debugger visualisers.

[DebuggerBrowsable(DebuggerBrowsableState.Never)] can be used to prevent the display of data, such as private fields, in visualisers.

In order to use the debugger attributes you will need to import the System.Diagnostics namespace. You can find out more about debugger attributes here: Enhancing Debugging with the Debugger Display Attributes.

One final debugging tip: you can hold down control key when drilling into a visualiser to make it transparent while you inspect the code beneath it.

If you’ve been a VB6 programmer at some point in your career, it’s pretty good odds that you would have heard of Dan Appleman (Visual Basic Programmer’s Guide to the Win32 API, Desaware). But did you know about one of his other interests? It’s probably one of yours also…His site thinkingaboutmoney is an excellent place to visit to pick up some of Dan’s common-sense advice.

Dan has recently published a 25 page e-book “The Graduating Geek’s Guide to High Finance” aimed primarily at recent graduates but it also contains advice for the rest of us. It costs US$3.99 and is well worth those few dollars.

It’s not a get rich quick scheme, but talks about the financial practicalities you should consider, even as soon as graduating and taking your first job. Some of the information is US specific (such as the super fund information), but the majority is applicable in any country. Dan discusses the importance of saving (and starting to save sooner, rather than later), trade offs with different types of investments and a worked example of why you should completely avoid credit card debt.

I think this is one of those areas that programmers often neglect. It is all too easy to get wrapped up in the technology side of things, and forget to take care of your finances.

Disclaimer: Dan provided me with a free review copy of the e-book, but my comments were not biased because of this.

Here are just a few of the principles espoused in the “Elements of Style” (see my previous post) which I have taken liberty with and made a few OO analogies:

Choose a suitable design and adhere to it. This pretty much stands alone as good advice in the context of writing or coding. Spend time on the design before you start coding. Don’t hastily start coding to one design, then change it, and then change it again.

Make the paragraph the unit of composition. As a general rule, start each paragraph either with a sentence that suggests the topic or with a sentence that provides a transition. This is similar to grouping like behavior into classes. A class should contain a well-defined set of related methods, not just a random collection of unrelated functionality.

Keep related words together. The principle means of showing the relationship of words to one another is their position. The intent is to give clear meaning, and not to confuse the reader by making sentences ambiguous. The analogy I tenuously liken this to is name your methods accurately, preferably with verb-noun pairing.

Use the active voice. The analogy here is objects being asked to perform a particular behaviour rather than being used in functional coordinated approach.

Put statements in positive form. This is akin to avoiding the double negative in poorly named methods.

Use definite, specific, concrete language. Put truly common behaviour into abstract base classes, place specific behaviour in concrete classes.

Omit needless words. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences. This could be restated as: A class should contain no unnecessary methods, a method no unnecessary lines of code.

Avoid a succession of loose sentences. Do not place inappropriate behaviour in classes. If things get too complicated, make more types.

Jeff Atwood has posted a ‘food for thought’, historical perspective of the evolution of programming languages, Fifty Years of Software Development, over at his Coding Horror site (yes, that is the actual coding horror graphic from Code Complete! If you’re a developer and you haven’t read Code Complete, drop what you’re doing and go order it from Amazon).

The Visual Basic 2005 PowerPack people have just released a PrintForm component to add back the functionality that was present in VB6. You can download it here: PrintForm Component 1.0. It will also work with C#.

A second edition of Steve Krug’s, “Don’t make me think” has been released. I’ve just added it to my burgeoning Amazon booklist. Steve has website here. It’s not exactly loaded with extra content but does have some interesting videos.

On the topic of one of my favourite subjects, usability, the headrush site is a gold mine of information. The latest post, Why they don’t upgrade (and what to do about it), contains this pearl, “People don’t upgrade because they don’t want to move back into the “[I] Suck Zone.”” I’m sure this is something Microsoft is spending considerable effort on with the approaching release of Vista.

Q: Have PC users queued up in the cold to buy a Microsoft OS since Windows 95? Kathy Sierra writes:

“By the time Apple releases a new version of Mac OSX, the Faithful are so
excited that they line up by the thousands outside Apple stores at midnight,
braving the cold, just to get the new OS a full 24 hours ahead of their friends.
How do I know? I’ve done it, twice. Once when it was snowing.”

Maybe Vista will get them queuing?

A few weeks ago, I posted a list of design principles for software development. Here’s a list of guidelines centered on the development process:

Development Principles

• #1: All change must be trackable. All development must be done utilising a Source Code Control system. SCC should be backed up at least as often as every night and should be the primary repository for all development.
• #2: Use an issue tracking system, preferably one that integrates with your Source Code Control system. Get developers to associate an issue ‘ticket’ when checking in source code.
• #3: Builds must be automated and your deployments should be buildable in a single step. Run nightly automated builds as a minimum. Consider using continuous integration. Anything that can be automated should be.
• #4: Run all tests automatically. Do not use manual procedures; that’s what computers are for! Create unit tests, preferably before writing any code (Test Driven Development). Run unit tests as part of the build process. Employ a code coverage tool alongside your unit tests.
• #5: Run automated user acceptance tests. Test early and often. Tests that run with every build are much more effective than manual test plans that sit gathering dust on a shelf somewhere.
• #6: Use code generation to increase your productivity and help avoid duplication. Do not use wizard code you do not fully understand. Look for repeated code patterns (such as Data Access Layers) and create templates to generate code from.
• #7: Keep a decisions document. It should be under source control. Record all design, architectural and development decisions, along with the reason for each decision, the date and where appropriate the participants involved.
• #8: When providing time schedule estimates, break tasks down to be less than 4 hours in total duration. Do not cave in to pressure from management to reduce schedule estimates when you believe they are accurate.
• #9: Make things easy to reuse. If things are easy to reuse, then it’s likely they will be. Strive for an environment that promotes reuse.
• #10: Perfect your use of debugging and diagnostic tools. Find the tools that suit your needs best, and get to know them well. Do not develop or debug by coincidence. Bugs do not go away by themselves!
• #11: Make your documentation part of the code; that way it is less likely to be out of date.
• #12: Use virtual development environments. VMWare and Virtual PC are both free. There are times when having a throwaway PC (or server) is essential: simulating a client site, creating a test environment, installing beta or trial versions of software, sandboxing dangerous code. Once a luxury, now a staple.
• #13: Strive for simplicity and consistency in your designs and in everything you do.
• #14: Understand your users’ expectations and then deliver just a little bit more. If your users become project champions, you know you are succeeding where others often fail.

I’d like to leave you with this parting thought from The Pragmatic Programmer:

Sign your work: In previous generations, master craftsmen were proud and eager to sign their work. You should be, too.

A while back, Jeff Atwood posted an article on managed code analysis tools and more recently on the benefits and the dangers of misusing code metrics. Static code analysis can help you to come to terms with an unfamiliar code base. Here are a few free useful tools:

• Reflector (there is a list of add-ins here and Peli’s code metrics add-ins): the essential tool for .NET developers. I do not think it is an exaggeration to say that every .Net developer should be familiar with this tool.
• FxCop (1.35): although it requires version 2.0 of the .Net framework, this version will still interrogate .NET 1.1 assemblies. It’s a valuable tool and now integrates directly with VS2005. Make it part of your automated build process.
• NDepend (2.0): analyses .NET assemblies and source code and generates quality metrics reports. There is a quickstart tutorial here.