Sometimes, when you join a new team as a .NET developer, the team lead proudly points you in the direction of a Word document or wiki page detailing the team’s house coding standards.

In my experience, these documents are invariably:

• Incomplete.
• Subjective.
• Not enforced.
• Largely copied from the interweb.
• Obsessed with the trivial (e.g. whitespace) while failing to mention the genuinely useful (e.g. boxing/unboxing, avoiding use of deprecated classes, Dispose pattern, etc).

I know this because I’ve been involved in creating such documents in the past

Don’t get me wrong, I’m all in favour of creating clean code, and promoting standards within a team. I just find that most in-house style guides fail to achieve this, for the reasons listed above.

So, as I was walking through the city today, I started having a little debate with myself. “OK then, smarty-pants. What’s your alternative? What would your in-house coding standards guidelines look like?”

I think it can be summarised by four simple points, listed in order of importance:

1. Don’t Ignore Compiler Warnings

You might think this would be an obvious one, but I’ve lost count of the number of times I’ve retrieved a solution from source control, compiled it, and been presented with a list of compiler warnings. Most of the time, there’s no excuse for this. If the compiler smells a rat in your code, then you’ve got a problem, be it variables that are used without being initialized, unused variables, unreachable code, or whatever. It’s sloppy code, and it’s easily avoided, so don’t leave it for the next guy to clean up. I am, if you hadn’t guessed, a big fan of setting the “treat compiler warnings as errors” flag in a project’s build properties.

2. Follow the Framework Design Guidelines

The Framework Design Guidelines is another one of those books whose name doesn’t do it justice. The sagely guidance it contains is appropriate not only to Microsofties developing the FCL itself, but to anyone writing any .NET code. Don’t let your developers near a copy of Visual Studio until they’ve provided a sworn affidavit confirming that they’ve read this book!

All of the guidelines are concisely boiled down into Do, Consider, Avoid, and Do Not recommendations, and you would do well to adhere to these. Getting a few copies of this book for your team is a much more effective and cost-effective approach than trying to develop your own coding standards.

3. Run FxCop

Having read and digested the Framework Design Guidelines, you need an easy way to enforce them. This is best achieved by running FxCop against your code (now integrated into some of the Visual Studio SKUs as a “Code Analysis” option).

Depending on the target audience for your solution, you may consider it reasonable to ignore some of the localization recommendations (i.e. when developing in-house line of business applications with limited geographical reach). But generally, if FxCop flags a warning in your code, I believe you would be well advised to correct the problem. Doing this helps to avoid a wide range of performance, security and design issues, in addition to enforcing consistent source code conventions.

4. Run StyleCop

Finally, if you simply must achieve that uniform source code appearance that the whitespace Nazis in every team strive for, consider requiring that your devs run their code through StyleCop before checking in. It may initially be a bit annoying, and for sure some of the recommendations are highly subjective, but there’s no arguing that it does enforce a standard style, with a strong focus on increasing readability and reducing ambiguity.

And After That…?

Following the four points above should result in the low-level codebase produced by a team being readable, of high quality, in a common style, and free of many common “gotchas”. It doesn’t validate the higher-level architectural considerations, but in my opinion that is outside the scope of such a document, and could best be achieved through the use of a tool such as NDepend. But that’s a topic for another post…

One of the multiple hats that I’m currently wearing for a client is that of SQL Server DBA. In this guise, I have recently fielded a couple of email queries from users concerned about the data recovery options available to them, should application data be inadvertently deleted:

“What kind of database backup and restore mechanism is in place for [application]? If someone deletes any data from [application] front end is it possible to restore it? Generally the way to recover data would be to restore the database from a database backup file, however this would restore all data held in the backup and would overwrite any changes made since the time of the backup.”

and

“If user A corrupts data entry in some way, and needs to go back to a version X of the database before the corruption, will user B also have to go back to version X and potentially lose any ‘good’ they themselves might have added since version X?”

I replied explaining that this is one of the many reasons for choosing SQL Server to provide the database back-end for critical applications, rather than, say, Access (don’t get me started on the prevalence of Access in mission-critical applications, it’s a bit of a bugbear).

If you have your SQL database recovery model set to Full or Bulk-Logged (and if not, why not?) then it is possible to restore from transaction log backups to a point in time. So, in a data loss scenario like those outlined in the emails above, you would take a backup of the transaction log, and restore a new copy of the database to a point in time just before the deletion. The missing data could then be copied from the restored copy across to the live database. Easy.

Even so, just because this functionality exists doesn’t mean you should plan to use it. Flipping back to my system developer persona makes me question why the application allows users to perform non-logged hard deletes? Soft deletes would be far preferable (i.e. setting a “deleted” bit on the relevant rows). Better still are ledgering systems (like the bank statement paradigm), which handle updates and deletions by making a change entry, or entering an offsetting transaction.

Earlier this week I picked up a hire car and headed over to deepest Cheshire to install an instance of Team Foundation Server 2008 for a client. Before setting off, I tried to make sure that all the prerequisites were in place – i.e. that there was a suitably-specced server available for use, which was connected to the domain, that all the necessary service accounts were created, and firewall ports opened, etc.

So, I kicked myself somewhat on arrival when I realised that the server was running a 64-bit OS, and remembered that the application tier of TFS only supports 32-bit. Doh! This blog entry is partly intended to prevent me from ever forgetting that again.

However, it all turned out fine in the end. There were other reasons why I didn’t relish the prospect of installing TFS on the box in question – namely that it was also being used as a domain controller and SQL Server (this isn’t as bad as it sounds – the server exists solely to provide an R&D development environment for a new project with demanding timescales). So, the solution I opted for was to install Virtual Server 2005 R2, and then install TFS on a virtual machine running a 32-bit OS. This worked well, as the host server was massively over-specced for the tasks at hand.

I think virtualization is a technology whose time has really come, it certainly makes it very easy to set up development environments like this one, where the number of servers required exceeds the number of physical servers available. Occasionally I come across posts on the web from people who’re trying to install, say, TFS, SQL Server, SharePoint, and Exchange all on the same server, and getting into a pickle. Don’t do it. Embrace virtualization. Developers know all about separation of concerns when designing software solutions – try the equivalent approach when configuring your development servers.

As an aside – the team chose to use Conchango’s SCRUM for Team System process template, which seems to work very well, and I recommend it for anyone running a project using the SCRUM methodology. Remember, TFS is process-agnostic, you’re not limited to using MSF.

What is it with software developers and their innate desire to reinvent the wheel at every opportunity? It drives me absolutely crazy when devs choose to roll their own implementations of standard structures instead of using the functionality already available in the .NET Framework.

Case in point – a coworker just emailed myself and others an "example of using generic collections". I was intrigued why an example of such a thing should be necessary in 2009, so I took a look.

To my horror I discovered that this supposed example of best practice included a hand-rolled implementation of the ICollection<T> interface, replicating entirely the functionality offered by Collection<T>. Already screaming inside at the futility of this exercise, I then noticed that this custom implementation was in fact using an instance of the non-generic .NET 1.1 ArrayList class for its underlying store. Ouchy!

Now, I know that the .NET framework is huge, and nobody can be expected to be au fait with everything it offers. BUT, I’ve said it before, and I’ll say it again:

If ever you find yourself thinking "gosh, this is convoluted" or "if only there was an easier way…" then, in all likelihood, there is indeed an easier way, and you’re making this far more complicated than they need be.

So, should you ever find yourself writing heaps of code to achieve what should be a common task, please, stop what you’re doing and try the following:

1. Search Google.
2. Search the .NET Framework documentation on MSDN.
3. Consult the .NET Framework Design Guidelines.
4. Post a question on StackOverflow asking for the best way to achieve your goal.
5. Swallow your pride and ask the guy or gal next to you.

Just don’t spend all day wasting your time and the client’s money reinventing the wheel and duplicating functionality that already exists in the framework.

Not wishing to be outdone by Joel Spolsky’s recent blogging about the fancy new Fog Creek office, I thought I should announce that we here at Ian Nelson Systems Limited are also getting a shiny new office!

Yes, now that baby two is on the way, the business is moving out of our small back room (which becomes a second nursery) and into… the room which was formerly our guest room! This affords me better natural lighting, and more shelving space for all those lovely geek books. Who needs views of the Statue of Liberty when you only have a three-second commute from bedroom to office?

Photos will appear in due course, meanwhile you’ll just have to gaze at this floor plan and use your imagination…

Despite the plethora of blogs, podcasts, and online videos that currently abound, I still prefer to get most of my technical learning via the trusty old dead-tree format.

Here’s a quick round-up of the techie books that I bought during 2008.

Inside Microsoft® SQL Server™ 2005: Query Tuning and Optimization

One of a series of four books digging deep into SQL Server (see my earlier review of The Storage Engine). A very in-depth book providing a holistic performance troubleshooting methodology for SQL Server.

Essential Windows Communication Foundation (WCF): For .NET Framework 3.5 (Microsoft .Net Development)

Not easy bedtime reading, but rather a truly essential book to have by your side when using WCF out in the field.

Test Driven Development (The Addison-Wesley signature series)

A classic treatise from Kent Beck, and a very entertaining read.

Core Memory: A Visual Survey of Vintage Computers

A reasonable coffee-table book from the folks at the Computer History Museum, but not entirely relevant to young whipper-snappers such as myself (although it does include a nice photo of a Commodore 64!)

LINQ in Action

One of the best programming books that I’ve read in a long time. This could have been a dry and dreary affair, but the examples and depth of coverage help to make the subject come alive.

NHibernate in Action

Setting a new world record for longest time from early PDF to dead-tree edition, this still isn’t out in hardcopy yet! But it proved very useful as I had the pleasure of working on my first NHibernate project during 2008, leading to my Damascine conversion to the world of ORM.

Calendrical Calculations 

Not strictly a computing book, but liable to be of interest to other IT geeks and calendar wonks like myself.

Working Effectively with Legacy Code (Robert C Martin) 

One of the best programming books I’ve ever read, this had a huge impact on my ability to write clean, maintainable, testable code. The title doesn’t do it justice.

Accelerated SQL Server 2008 (Expert’s Voice)

A good introduction to SQL 2008, but loses a star for including information about features which were introduced back in SQL 2005. This could have been several hundred pages shorter, IMHO.

Continuous Integration: Improving Software Quality and Reducing Risk (Martin Fowler Signature Books)

Short but enjoyable book explaining reasons, techniques and resources for implementing Continuous Integration across the whole development lifecycle. Another one of those books you wish your boss would read…

Pro WF: Windows Workflow in .NET 3.5

Haven’t read it yet

Developing Solutions with Microsoft® InfoPath™ (Pro-Developer)

Sent this back when I realised it only covered InfoPath 2003, and I was interested in 2007 – doh!

CSS: The Missing Manual

A great read for anyone who has dabbled with CSS and now wants to learn more about this sometimes opaque subject.

Professional BizTalk Server 2006

Haven’t read it yet

Refactoring HTML: Improving the Design of Existing Web Applications (Addison-Wesley Signature)

Another book whose title doesn’t do it justice – this book is full of great advice for structuring HTML, whether on a new or existing site.

Managing Projects with Microsoft® Visual Studio® Team System

Not my cup of tea, a bit dry and theoretical for my liking. More aimed at pointy-haired types than developers.

Software Engineering with Microsoft Visual Studio Team System (Microsoft .Net Development)

A good overview of the capabilities of VSTS and how they can be applied to the software development lifecycle.

Visual Studio Team System: Better Software Development for Agile Teams (Microsoft .Net Development)

My favourite book on software development methodologies using VSTS, this should help any team of developers adopt an agile approach.

Team Foundation Server 2008 in Action

Finally, a really good TFS book for developers. See my earlier review.

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reuseable .NET Libraries (Microsoft .Net Development)

I adored the first edition of the Framework Design Guidelines, and firmly believe that all .NET developers should read this book.

Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset 

An excellent detailed description of how to apply the Kimball Methodology when creating a Data Warehouse / Business Intelligence platform using Microsoft SQL Server 2005.