Due to a peculiar set of circumstances I’m looking at C# coding standards or style guides. The key decision is to agree to a style guide that everyone more or less follows. I also like style guides that go a bit beyond how to format the curly braces on a newline or tabs versus spaces. I like rules like this:

Define small classes and small methods.

— Rule #69 The Elements of Java Style

At a previous organization:

1. I bought a bunch of copies of The Elements of Java Style.
2. I handed them out to all of our developers.
3. I ran a brown bag lunch covering the top 10 rules I wanted them to concentrate on.
4. We checked most of the style items in the continuous build with Checkstyle. Gentle enforcement.

A quick perusal of the C# world says there isn’t any base coding standard like Sun’s Coding Conventions. I’m a bit surprised since I expected Microsoft to have at least attempted to do so, but other than the things you can glean from heaps of example code it doesn’t appear they have a well documented default.

The candidates from fifteen minutes of googling appear to be:

• C# Coding Style Guide from icsharpcode.net.
• The iDesign C# Coding Standard. from iDesign.
• C# Coding Standard from Philips Medical Systems.

The ic#code standard is concise and covers the basics. The iDesign option is more comprehensive. A quick skim did found a rule I don’t agree with:

Avoid methods with more than 200 lines.

Two hundred lines is ripe for refactoring to many 10-20 line methods. Still it is a lot more in depth. The final Philips standard attempts to combine rules from their C++ Coding Standard, the ECMA C# language spec, and an MSDN Design Guidelines Library Development document.

I’m pretty open at this point to suggestions from any of you who have spent a lot of time in the C# trenches.

I recently rotated through a different management position for a weekend. It was still in IT, but I walked home late on Sunday realizing I learned a heck of a lot.

As a long time professional services guy I often miss the freshness of the new client. Just some of the clients I got to work with in a single year:

• Fortune 500 pharmaceutical company
• Multiple app server vendors
• Online learning business
• State of California licensing agency

Managing within a corporate IT arena you do get different challenges and you have a variety of internal business customers, but it’s still centered around the same business context.

I’ve been with the new company for about 6 months now and I’m still stumped by a fair bit of acronyms. I have gotten comfortable operating within the development sphere and a pretty constant set of business customers. Working as the weekend manager for a different IT group gave me some perspectives I wouldn’t have gotten any other way.

The most valuable part of the weekend was talking to various folks on other teams about how they saw the work they were doing and what they’re value proposition was. They were all tired. (This was weekend work) A lot of them were a bit down on morale. They all were trying to do the right thing. I made a few of them laugh when I asked basic questions about things they’d been doing for years. Like, “don’t you just reject a patch if the install instructions are all wrong?” The answer turned out to be no.

Taking a dive into a different area especially an area of the business works out your brain. I thought I’d be tired coming in this morning after working 12-14 hour days over the weekend, but I came back recharged and doing a bit more strategic thinking. And I can bring what I learned back to my team.

Getting DSLs to be business readable is far less effort than business writable, but yields most of the benefits.

— Martin Fowler

Software transparency to business experts is a great goal. I’ve met plenty of sophisticated business users who at least could do some basic SQL and whip together lots of nice reports in Excel. Those same users when presented with Java code lean back in their chairs and wait for the developer to show them a screenshot. Getting a DSL they can actually read and give feedback on means higher quality software.

I can’t claim to have reached this goal despite some attempts. So far the closest was a Fitnesse implementation validating business rules in some vendor software. The testers really took on creating scenarios after it clicked for them, but the business analysts still found it a bit to rough around the edges. Baby steps.

Fowler nails the point of DSLs from a business perspective. It sounds great to talk about business users writing the rules for the software. Every rules engine vendor makes this claim. In practice I’ve never seen it happen. Developers end up writing the business rules in the syntax of the particular engine.

Creating readable DSLs is great if you can communicate with the business experts. And even if you fall short the developers/testers get clear concise code out of the exercise.

Flipping through the Google Chrome documentation my brain was screaming–“This has to be Scott McCloud“. Turns out it was. Scott was a big deal back in the dot com days with his book on “Understanding Comics” and it’s applicability to designing web sites. I actually saw a great talk from him back at the Web 99 conference in SF. (That would be 1999). Nice to see him crossing back into the web world again.

The Chrome documentation is one of a number of new documentation styles I’ve seen recently. Screencasts are also becoming a popular way to do documentation and not just for high profile Web 2.0 frameworks but small internal IT apps. One consultant told me he had started doing all the documentation for their custom IT apps as screencasts. The customers love it because they can figure out how the app works quickly without running painful conference rooms of training sessions. And the flashiness of it is a bonus as well. To top it off it generally only takes a few hours for the developer to put it together. He mentioned the Peepcode screencast by Geoffry Grosenbach on Screencasting on the Mac was one of the best investments he’s made in a while.

As a developer, especially a developer who is comfortable building servers and slinging code in vi, you don’t want to hear the no word from the sysadmin. You want to be agile and install your own app. You want to configure the extra JNDI settings yourself. And you’re wrong.

I’ve worked in environments where sysadmins ruled with an iron fist on their environments and never let developers on production even to grab log files. Other places developers had wide open access. Wide open access is a bad, bad thing unless you’re still a small startup. Here’s the best model for a corporate IT shop.

• Developers own development for the most part. Sysadmins may backup the server on some filesystem, but that’s about the extent of it. Source control, wikis, continuous integration all run here. Developers are the primary users and everyone else is just visiting.
• Test is all about the testers. Testers should have access to tools like bug trackers and automated testing tools or servers. All the test servers should be locked down with developers and testers given read access to things like log files. Here the sysadmins begin to exert more control because test is the first step formal step in moving an app to production.
• Staging is a pure environment and developers are locked out here.
• Production is a no touch environment. Sysadmins have full control and troubleshooting issues means the developer sits with the sysadmin and doesn’t do the typing.

Developers need to stay focused on quality and not jump around troubleshooting environments. Good sysdamins will say no to developers touching production, but they’ll work closely with them to automate deployments and configuration. Remember they’re saying ‘no’ for your own good.