I recently picked up some domains for my next open source project - G+ Notifier. It's a simple Windows utility that'll sit in the notification area and alert you to notifications from Google+! Similar to my previous Google Wave Notifier, but hopefully Google won't discontinue this service quite so quick!

I'm not sure if I'll be able to launch the application before Google+ gets a public API, but I'll do some investigation over the coming days.

If you want to be kept informed with the progress of the app, please follow G+ Notifier on Google+, I'll post all updates on that account :-)

The website for the application is gplusnotifier.com and will also be updated regularly. Full source code will be hosted on Bitbucket!

I was recently discussing the value of comments in code with some colleagues. After the discussion, one of them sent me a link to "Don't Waste Your Time Commenting Source Code" written by Riyad Mammadov.

I have to say I'm both shocked and disappointed that there are developers out there that have this opinion. And there seems to be quite a lot of them. I'm quite passionate about code comments because I spend the huge majority of my time maintaining/debugging/fixing code written by other people that has no comments (other than commented out code...). I waste an enormous amount of time stepping through code with a debugger, just trying to understand WTF it's trying to do.

I know some developers that always respond "The code is self-explanatory". This is a garbage excuse from a lazy programmer. There are a few reasons why this argument is not valid:

1. It might be self-explanatory to you, but there are other developers here that may need to maintain your code, some less skilled than others.
2. Unless you're a compiler, reading an English comment is far quicker than parsing code in your head.
3. It's rarely clear from code why it does what it does.
4. Reading code only helps you understand what it does, not what it was intended to do. This would be fine if you wrote flawless code. You don't.

In addition to this, we often have to write less-than-ideal code. You might find a bug, and to work around it, change some nice clean code to something a little bit hacky. If you don't comment why, there are good chances that someone will come along, think "WTF, this could be done better" and refactor your code, re-introducding the bug. A simple comment saying "Can't do this using X, because it causes Y to fail" could save a lot of time and effort.

Back to some of the points made in Riyad's article...

I strongly believe that 90% of source code comments are a waste of time

I think Riyad is a little confused between code with crap comments, and code that doesn't need commenting. I can't possible agree that only 10% of all code written is worth commenting. I might agree that only 10% of code comments are useful, but that just means the developers are failing at writing good comments, not that the idea of writing comments is bad. A huge portion of useless comments on code could be replaced with useful comments.

if you think about it, a well-designed program doesn't need comments to be maintainable

This really is tripe. Code does not convey the *reason* you are writing it. Here's an example from some real code:

// When the transition finishes, hide the screen. We don't remove it,
// because we want it to come back when the covering screen is dismissed
this.ScreenState = ScreenState.Hidden;

Without the comment, it might not be clear why the screen is being hidden, instead of being removed. Somebody that's not familiar with the code (which, six months after it being written, is everybody, including the author). The comment makes this pretty clear why the code does what it does.

If the choice is between a well-designed program without comments and a thoroughly commented but poorly architected one, I will choose the former any day of the week

I don't understand the logic here. There is some suggestion that writing comments comes with a penalty that somehow affects the architecture of your system. I think a more valid comparison whould be "Unfinished, but commented code" vs "Finished, but uncommented code", and I would absolutely take the commented code any day. It's unlikely that it'd take longer to finish a well written, well commented application than it would to try and understand thousands of lines of uncommented code.

Riyad shows some sample code to illustrate his point:

/**
 * Always returns true.
 */
public boolean isAvailable() {
    return false;
}

There's no argument here. This comment is pointless. However, there's some suggestion that because this comment is pointless, this code does not need commenting. That is absolutely not the case. The comment is crap. It should be replaced with one that is not crap.

Not writing code comments because some people write crap comments is like not writing code because some people write crap code.

Sadly the biggest loser in all this is not the developer that's not writing comments, but his colleagues. They'll struggle to maintain his uncommented code while he easily understands their well-commented code :(

Update: Today I had a lengthy chat with Paul Foster, a Microsoft Developer Evangelist, about this post. I posted an update here.

Ever since I had my first iPaq with the .NET Compact Framework, I've wanted to code for a Microsoft mobile device. Coding in C# and Visual Studio is by far the nicest coding experience I've come across in the 15 or so years I've been programming. Unfortunately, up until now, Microsoft's mobile operating systems have all been absolutely rubbish.

Windows Phone 7 is set to change all that. Everything I've seen suggests Microsoft have finally got their act together, and WP7 looks set to be a huge success. Finally I can have the Windows phone I've always wanted!

Over the past couple of months, I've been reading more about developing for Windows Phone 7, and in the last few weeks, I've been playing around with both Silverlight and XNA as part of this. The experience is great, and I've been really looking forward to working on a game for WP7. I've spent the last few months of my spare time working on an iPhone app, and it's so nice to be able to switch Xcode/Objective-C for Visual Studio and C#!

However, there may be a problem...

I was just pointed to this page by a fellow XNA coder. Although not entirely clear, my interpretation of this text surprises, and shocks me. (Emphasis mine).

To answer, it's important to understand that we have a managed portfolio for Xbox LIVE titles on Windows Phone 7. As we looked at how the mobile gaming industry was evolving, it was obvious that there's a significant problem with the "race to zero" – or having too many, mixed quality titles available on a marketplace. Too many offerings makes it very hard for any specific title to stand out (no matter how high-quality), and negatively impacts the overall business ecosystem by making it almost impossible for developers to earn a fair return on their work. Our goal with the Windows Phone 7 games that utilize Xbox LIVE services is to cultivate a portfolio of high-quality titles that are regularly released – this is very similar to the portfolio management we do for Xbox LIVE Arcade titles.

This sounds to me, an awful lot like the current Xbox LIVE Arcade situation. Indie titles (eg., those created by people that do not have commercial relationships with Microsoft) are relegated to a crappy sub-category of "Indie Games".

You may be wondering what the big deal is here - surely we want to keep all this "indie crap" generated by bedroom coders hidden away so we can see stuff output by the real companies, eh? Well, not so. Not only are there "real games companies" that develop this way (because they're just not big enough to have this kind of relationship with Microsoft), there are also a lot or really good quality games output by "bedroom coders".

If you look at the Apple/iTunes App Store, every application or game sits equal. A game I publish, sits alongside a game published by a large company like EA. There are "league tables" for ratings and sales, which allow the best games (whether they're from a large games publisher, or a single coder in his bedroom) to rise to the top. For all of the faults with Apple's App Store, this is how it should be. If an individual puts out some work that is better than EA, then it deserves to be above them. Consumers care games, not about the companies (or individuals) behind them.

I have no real idea, but I would estimate that at least 75% of all apps/games on the App Store are created by individuals or companies too small to have relationships with Microsoft. That is a huge portion of apps/games to relegate to "the shit section". One of the reasons the iPhone did so well was because of the third party software. If Microsoft screws over the huge majority of developers like this, it will absolutely affect the success of their platform. We're already lacking things like Achievements - it's already going to be hard to convince users they should buy our game instead of EAs's, so pushing us into the amateur category will just make things harder (And therefore, less worthwhile).

My interpretation of the quoted text may be incorrect. I really hope it is. It's also possible this affects only games, and not apps. Who knows? If games created by me are relegated on Windows Phone 7 like they are on the Xbox, then I'll simply put up with Xcode/Objective-C, and go back to coding for Apple's platform. And this means, despite my desite for a WP7 phone, I'd probably end up buying a new iPhone, and not a WP7 phone.

Until this little mystery is confirmed, one way or another, my WP7 game is on hold :-(

After Mark Wilson-Thomas, the Program Manager on the WPF Designer team responded to my post about my WPF issues, I thought I owed it a second chance having read his comments.

Locating Controls

My first issue was with the control drop-down being removed. Mark pointed out a few alternatives like the Document Outline window and the XAML Path control. The Document Outline seems to work pretty well, though I'm still not covinced I'll get along with it. Usually when I'm heading for the old drop-down at the top of the property grid, it's because I need to select something I can't easily select in the designer (menu items, controls that are dynamically hidden/shown etc.), and I usually have the name of them in my head. That makes an alphabetical list much quicker than a tree. I know what the item is likely to be called, but not necessarily how it's embedded in a huge tree of SplitPanels. I've also noticed a few minor issues as you can see in my screenshot.

The tree is a bit flat, and not very tree-like, so it's not easy at a glance to see the hierarchy. While this might not seem like a big deal since the drop-down I love was flat, but since the items aren't sorted alphabetically now, it can be a little tricky to find your item. Though this might get easier the more I use it! The other issue is that the small preview appears squashed sometime. I'm not sure if this is a bug, or if it's by design, but the button shown in mine doesn't quite look like the actual button on the form.

The XAML tree is pretty nifty, though a little fiddly to use. You can very easily select a parent of the currently selected item, and an arrow (" /> ") list children. While this is pretty powerful, since it only deals with parents/children, it's probably more likely you'll get into the habit of using the Document Outline instead.

Adding Non-Default Event Handlers

Mark pointed me at Chuck Sterling's blog showing new intellisense that can add event handlers. I'm still not convinced this is as nice as being able to easily see a filtered list of events, it's a nice addition. This would be much more friendly if there was a quick way to filter the intellisense to just list events (though I suspect there won't be).

Finding Properties

Mark hinted at "a better way of locating the properties in the property grid before we ship" which I suspect might be live filtering of properties like in some of the Expression tools (a search box, that hides properties that don't match what you're typing). Withing seeing it, I can't say whether it'll be as natural as looking for properties based on what letter they start with, but I'll post my thoughts when if and when I see it.

Rendering Issues

As for the rending issues, I managed to get a screenshot of the kind of thing I'm seeing. This particular issue shows up when I hit "Swap Panes" to replace the XAML with the Design view. It always renders the hosted WebBrowser control, but nothing around it. When I click anywhere on the surface, everything else appears.

Here's screenshots showing what's displayed after clicking the "Swap Panes" button and the expected view (which happens when I switch to XAML then back to Designer normally).

Update:

I've posted to the Cider Forums as requested.

Visual Studio 2008 Beta 2 is now available. That means all of the cool things Microsoft have been tempted us with for the last few years are available to use: Linq, Linq to SQL, Lambda Expressions, (more stable) WPF Designer!

Something I didn't realise until now, is that the "WPF Application" option hasn't replaced the old "Windows Forms Application" option. You can still create .NET 3.5-targeted, good old Windows Forms. As it turns out, it's a good job, because the WPF designer just doesn't cut it. Here's some things I noticed within 5 minutes of trying to build a simple WPF App:

• The property grid doesn't have an option to show Events
• The property grid doesn't have an option to sort alphabetically
• There's no drop-down above the property grid showing all the objects on your forms
• There are massive rendering issues in the designer on my machine (Vista)

Being the final beta and with a Go-Live licence, I was hoping this was all going to be pretty stable, but it really isn't good enough. Sure, the property grid looks like a complete rewrite in WPF, and I admire them for that, but unless it's going to ship working at least as well as the old one, is it really worth it?

The final point, about rending issues is quite a bug. Sometimes controls just don't appear on the form until I click where they should be. If I run my application and then close it (so VS gets focus back), the form is completely blank. Waving the mouse around clicking reveals all of the controls.

All in all, I'm not impressed with the WPF Designer, and I won't be building my next application in WPF!

I don't know how Microsoft choose to categories their properties, so I always use A-Z view. When I've got controls obscuring other controls, I used to use that nice drop-down. Why must I know switch to XAML just to find my control? Why must I go via XAML to see my event handlers?

Let's hope this changes before VS2008 ships!!