Tools to Help With Unfamiliar Code

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.

TCP Tracing

If you want to perform tracing on a web service or site that you’re developing, there are several tools out there. SoapScope is great for debugging web service calls on the wire but it costs US$299.00 for a one year license. The good news is there is a free option; namely TCPTrace and it does not require an installer. TCPTrace acts as a tunnel between a client and a server and displays requests and responses received.

If you can’t do port forwarding then there is also ProxyTrace and YATT (at the same site). Other tools like Ethereal are great but they alter your network stack, so if you want a non-invasive approach TCPTrace is a simple and free solution. [I saw this quick tip via Scott Hanselman’s developer productivity tools talks.]

What is Refactoring?

A non-programmer recently asked me what refactoring is. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the system, but improves the internal structure of its code, making it easier to understand and maintain, and thereby reducing the cost of making subsequent changes to the system. Refactoring goes hand-in-hand with unit testing. Each unit test, should test a single method for a single set of inputs against an expected result.

  • BEFORE you start refactoring, check that you have a comprehensive set of tests. If there are no tests for the method you are about to change, first write ‘enough’ tests to cover the existing functionality. Tests should have as few external dependencies as possible. The greater the code coverage of the tests, the less the risk of introducing errors.
  • When refactoring, make changes in small steps. If you make a mistake, it is then easier to find the bug (provided you have a comprehensive test suite!).
  • When you need to add a feature to an application, and the application’s code is not structured in a convenient way to add the feature, first refactor the application to make it easy to add the feature, and then (and only then) add it.
  • I cannot over stress the importance of good naming. Never be afraid to change the names of things to improve clarity. If you find yourself unsure of how to name a class, it is probably an indication that you should try and split it into several, smaller classes.

I’m sure everyone has seen code at some point and thought “I should really change that, but I’ll have no way of knowing if my changes will break something else”? I know I have. Unit tests with ‘sufficient’ code coverage give you the courage to make radical code changes.

The unit testing tools you should take a look at are NUnit and NMock as a starting point, and then MbUnit and RhinoMocks. TestDriven.Net is a Visual Studio add-in that enables unit tests to be run from within the IDE. Automating your unit testing can be done using NAnt and
CruiseControl.NET (as well as several other tools including MSBuild). What are you waiting for? Write some tests and get refactoring!

Productivity Tools for Developers Webcasts

The unstoppable developer machine they call Scott Hanselman posted a very watchable, short series of video webcasts back in August (I just got around to watching them!), on the subject of developer productivity tools. You can download all four parts for online viewing from here Developer Productivity Tools Video Part 4 (download links are towards the bottom of the page).

  • Part 1 talks about Notepad2 (which is great for non-ansi character sets), some command line features you may not know about (or have forgotten), Process Explorer from SysInternals, Reflector from Lutz Roeder, and some .Net basics.
  • Part 2 looks at some aspects of Serialization (includes a great tip on how to debug into a .NET XmlSerializer generated assembly), SlickRun, xplorer2, Far (Norton Commander rides again!), Google Desktop, junctions.
  • Part 3 is a great introduction to PowerShell.
  • Part 4 covers CodeRush, TCPTrace for tracing web service traffic, XmlDocViewer.

The Art of Writing Clearly

If you can’t express yourself well in words, how can you expect to write clear, concise code? Joel Spolsky makes this point many times over. In fact, he goes as far as saying: hire programmers that can write well. And I agree. Given the choice between two programmers of similar skills and experience, I would pick the one with the best writing skills. Joel makes some excellent points here Painless Functional Specifications – Part 4: Tips. Paul Graham makes excellent sense in Writing Briefly; I’ve been trying to follow a similar methodology for some time.

If you want to improve your ability to write clear code you need to improve your English writing skills. If you want to improve your writing skills (apologies in advance, to everyone for who English is not their first language), a good starting point is buying and reading the book “Elements of Style” 4th Edition by William Strunk and E.B. White. Incidentally, this was the book that provided the title inspiration for Brian W. Kernighan and PJ Plauger’s “The Elements of Programming Style”.

The “Elements of Style” is a tiny book; you could add it to your rucksack or briefcase without extending your arms that bit more! In fact, it’s small enough to carry in your pocket. The fourth edition is a little gem. I highly recommended you buy and read it, and then keep it close, so you can flick through it from time to time.

A Few More Quotes…

Several people left comments when I posted a few of my favourite quotes, so here’s a few more.
The first quote in this list is from possibly one of the most brilliant men to have every lived, and one of my heros. I would have dearly loved to have met him.

I’m smart enough to know that I’m dumb.
Richard Feynman

A little knowledge is a dangerous thing.
Alexander Pope
[From an Essay on Criticism, 1709:
“A little learning is a dangerous thing; drink deep, or taste not the Pierian spring:
there shallow draughts intoxicate the brain, and drinking largely sobers us again.”]

Success is the ability to go from one failure to another with no loss of enthusiasm.
Sir Winston Churchill
He has all the virtues I dislike and none of the vices I admire.
Sir Winston Churchill

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
Martin Fowler

All you need is ignorance and confidence; then success is sure.
Mark Twain

If you tell the truth you don’t have to remember anything.
Mark Twain

It was on fire when I found it!
– Anon

The Joy of (Deleting) Code: Less is More

I love coding! I can still remember when I first discovered programming at the age of eleven. At that age it filled me with a sense of wonder and it had the feel of a black art! But there’s one thing I like more than writing code…and that’s deleting it! That’s right, I just love deleting code.

Less code can mean less errors and less ‘cognitive friction’ when reading it, and therefore easier to maintain. I’m not talking about code that’s a candidate for the next obfuscated C competition! I’m talking about lean, simple, concise and precise code with no duplication.

The work days I like the most, are those when I leave work having refactored a large chunk of code (be it mine or someone else’s).

Liberate yourself, delete some code today!

Favourite Quotes…

OK, this is not a technical post, but I do like succinct, pithy quotes. They seem to sum up what we often do as developers, that is, reduce things to simple, but information rich forms, meme’s if you will. Here are just a few of my favourite quotes:

In the land of the blind, the one-eyed man is king.
Erasmus

Any society that would give up a little liberty to gain a little security will deserve neither and lose both.
Benjamin Franklin

Those who cannot remember the past are condemned to repeat it.
– George Santayana
(often paraphased as: Those that ignore history, are doomed to repeat it.)

Those who can make you believe absurdities can make you commit atrocities.
– Voltaire

Never hold discussions with the monkey when the organ grinder is in the room.
– Sir Winston Churchill
History will be kind to me for I intend to write it.
– Sir Winston Churchill

Everything should be made as simple as possible, but no simpler.
– Albert Einstein

Any fool can defend his or her mistakes … and most fools do.
– Dale Carnegie

Windows XP Service Pack 2 Support Tools

Every so often (actually quite often!), I come across something and I think “I really should have known that!” (bit like the F7 key in a command window…). Some time ago, pre-.NET in fact, I was playing around with some VB/Win32 API code written by L.J. Johnson, and put together a simple app. to display (among other things) domain group membership. I’m sure I’m the last person to know this but Microsoft have a freely downloadable set of Windows XP Service Pack 2 Support Tools that includes whoami.exe that can display your SID and group membership:

C:\> whoami /USER /SID

[User] = “HOMEDOMAIN\mitch” S-1-5-21-1935655697-117609710-839522115-1003

C:\> whoami /GROUPS
[Group 1] = “HOMEDOMAIN \None”
[Group 2] = “Everyone”
[Group 3] = “HOMEDOMAIN \Debugger Users”
[Group 4] = “BUILTIN\Administrators”
[Group 5] = “BUILTIN\Users”
[Group 6] = “NT AUTHORITY\INTERACTIVE”
[Group 7] = “NT AUTHORITY\Authenticated Users”
[Group 8] = “LOCAL”

Saw this via Bart De Smet’s blog.