Archive for July, 2009

MobileTFL 1.0.0.8

Friday, July 31st, 2009

A quick note: I’ve upgraded MobileTFL to version 1.0.0.8.

Get it here.

+Improved loading speed (less start up lag)
+Fixed critical bug due to data format changes

I’m planning on listing this app on Windows Mobile Marketplace when it launches later in the year for a small fee (£1.50 ish).

Don’t be alarmed if you see this happen. The software will remain free to download from the web (likely relocating to www.electricheadsoftware.com), however there will be above mentioned small fee for those wishing to show support / download it off Marketplace to cover initial costs (certification / enrolment in Marketplace isn’t free).

I’m looking forward to seeing how well a small utility app can do in the wider Windows Mobile “consumer” market as a test bed for a few future projects. I’d appreciate it if people showed support if they fell it appropriate.

After some radio silence – videogames!

Monday, July 6th, 2009

Iíve not written in awhile as Iíve been busy moving to the other end of the country.  Iím now in London (Clapham Junction) rather than Manchester and slowly but surely settling in to my new life.  Iím still living out of boxes and preparing for an ISP change, so Iíve not really had time to do too much development (on a laptop, please, the poverty!) but what I have been able to do is play a good load of Xbox 360 games.

So a little executive roundup, in order of releaseÖ

  • Bionic Commando

    Interesting one this, I didnít pick this up on release week, as I have a habit of doing with most games that look ďpremiumĒ due to mixed reviews floating around the web.  I think it was the Kotaku review that swayed me to pick it up (that and a £30 price point in Tesco the week I was packing all my belongings into boxes).  I actually really enjoyed the core game play mechanics of BC.  I went in expecting something like Crackdown and didnít get it.  What I did get was a pretty tight modern 3d Contra game.  The internet said it was difficult, and after initially being disappointed that it wasnít, the game spent the final third of the game throwing three hundred sodding mechs at you at the same time.  Enjoyed it up until thenÖ oh and the end of the game is hilariously bad / amusing / poor / brilliant. 

    Enjoyable, but Iím not sure if Iíd recommend it.

  • Fuel

    I looked forward to Fuel coming out.  I liked the previews, I thought it looked really decent.  I like Fuel but itís not a good game.  Fuels gimmick is that theyíve used satellite imagery to render an massive open game world (talking hundreds and hundreds of square kilometres of, well, dirt) and thrown a bunch of ďextremeĒ weather in there.  Only, the vehicles donít remotely handle like cars, the core game play mechanic of ďracingĒ is really poorly implemented (you loose every race until the quarter of the final lap, then get to catch up) and generally there isnít too much game to be had.

    Thankfully thereís a free roam mode, where you collect car customisation bits that make not a single piece of difference to the game play experience.  Fuel is just plain boring and I canít recommend it to anyone.

    However, I oddly find myself enjoying Fuel.  I like exploring the largely bland (think Yellowstone National Park but with some poor texture work) massive environments, driving in one direction for literally half an hour (the map really is that big, big enough they let you teleport around it). Itís somehow therapeutic. So I guess, while I canít honestly recommend it, you might enjoy it if you like endless sandbox driving.

  • Red Faction: Guerrilla

    Iíve only really spent about 3-4 hours with Red Faction, and only with itís single player.  I really really like Red Faction, but honestly I just got really bored playing it after awhile.  The core game mechanics behind the game are brutally fun.  Everything explodes, literally everything.  The combat is pretty difficult, and blowing up just about every building in the game is incredibly fun.  Unfortunately the game is set on Mars, so everything is red.  And I mean everything.  If you think Quake looked brown, just wait until you see the red in this.

    The tech behind the game is pretty excellent, there are tonnes of excellent pacing mechanics to lead you through the open world game, they stage game progression pretty well, but itís all a littleÖ soulless?  I donít know, something just didnít quite grab me despite the game clearly being excellent.

    I guess Iíll get back to you on it.

  • Prototype

    The game where you get to karate kick a helicopter.  Seriously.  When I turned Prototype on I was pretty disappointed Ė largely because the texture work throughout Prototype is actually woefully bad.  Like really, 2003 Xbox game badÖ and then three seconds later they give you the super-powers of Spiderman, The Incredible Hulk, Wolverine and er., Bionic Commando.  At once.  Prototype is equal parts a kind of rubbish looking version of Crackdown with a far far worse environmental traversal component and part Devil May Cry rip off (I donít rate DMC) where you play, to the best of my knowledge some angry hoody.  The story is trying to be graphic-novel cool along with dramatic and really, itís just utterly lame.  But you donít care, because the game play mechanic is incredible FUN.  Not clever and not big, but you get to use your weird whip arm to pull helicopters out of the sky and sprint up skyscrapers while fighting mutants.

    I really canít say a bad thing about a game with a core mechanic so fun that it overcomes both terrible art assets and a woefully bad story, two things that I tend to hold in high regard.  Iíd recommend it.

Oh Iíve also purchased and got re-engrossed in Fallout 3: The One That Raises The Level Cap To 30 And RetCons Out The Ending. Fallout 3 is pretty much still my game of last year, so being able to continue made me very very happy.  Looking forwards to Telltale Gamesí Monkey Island episodes that start tomorrow and Iím positively lusting after Mass Effect 2 after the E3 teaser (along with, surprisingly, New Super Mario Brothers Wii).

As ever, make your own decisions, but Iíd recommend you check out at least a few of the above games.

Xml Comment Hell – A Software anti-pattern

Monday, July 6th, 2009

One of the most valued practices in software development is brevity.  Writing code is bad.  When you write code you create bugs, and creating bugs is bad.  The solution?  Donít write much code.  Commenting your code however, has traditionally been seen as a ďgood thingĒ.  So much so that most modern programming environments make some provision for document generation and offer style-guidelines for commenting your code.

I believe, however, that excessive commenting is actually an anti-pattern and should treated with caution, and as far as possible, avoided.  Iím going to illustrate my point with a (somewhat contrived, but in no way unusual or outlandish) example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace XmlDocumentationAntiPattern
{
    /// <summary>
    /// XmlCommentHell
    /// </summary>
    /// <example>var xmlCommentHell = new XmlCommentHell</example>

    public class XmlCommentHell
    {
        /// <summary>
        /// Description
        /// </summary>
        /// <remarks>String description of XmlCommentHell.</remarks>
        /// <example>instance.Description = "some description";</example>

        public string Description { get; set; }

        /// <summary>
        /// XmlCommentHell ctor
        /// </summary>
        /// <param name="description">Description string</param>

        public XmlCommentHell(string description)
        {
            // Assign description
            Description = description;
        }

        /// <summary>
        /// Gets the description property, but in reverse!
        /// </summary>
        /// <returns>Reversed description</returns>
        public string GetReversedDescription()
        {
            return Description.Reverse().ToString();
        }
    }
}

The context of this example is C# but similarly applies in other programming languages.

If you find yourself engaging in XML comments like the above example, I really believe ďyouíre doing it wrongĒ.  Why?

  • Reduced code readability

    The Xml comment clutter in the code above actually reduces itís usefulness.  The code now takes three times as much screen real estate to maintain and understand.

  • Low signal to noise ratio – too many characters that add no value

    When youíre maintaining systems however large, the act of actually writing code takes time and adds maintenance overhead.  Past the visual unpleasantness the amount of mark up required to document relatively simple methods actually reduces the codes utility.  Only ever type ANYTHING in your IDE if it adds value.

  • Incredibly obvious comments

    Thereís a wonderful quote to the tune of ďalways pretend that the person thatís going to maintain your code is an axe wielding manic who knows where you liveĒ.  Iíd like to extend that by adding ďso donít insult their intelligenceĒ.  There are few things I find as frustrating as reading comments that not only add no value but also make me feel like Iíve wasted a tiny piece of my life reading them.  Donít waste your time or mine.

  • Violating the DRY principle

    The DRY principle is very well agreed upon in software development.  Donít repeat yourself.  If your XML comments just repeat your method signatures, youíre not only repeating yourself (and thus wasting time) but youíre leaving yourself open to a maintained nightmare as the code changes and the comments are left unchanged leading to confusion and misinformation.

  • Possible misuse Ė the generation of utterly useless documentation

    When I see projects documented in this way I often joke that someone should run Sandcastle or javaDoc over the code to gain some tangible value in the form of MSDN-esq documentation.  Iím actually wrong.  This is a terrible idea.  Pop quiz time!  Whatís worse than tedious documentation that adds no value?  Tonnes of hyperlinked documentation that adds no value!  Think of the poor developer wasting minutes to hours searching for the value in generated documentation before painfully realising that thereís none to be had.

I occasionally get met with some resistance when I state my opinion on this for a couple of reasons.  People often argue that they do it for the sake of intellisense and IDE tooling, that they do it for generated documentation or just out of habit.  I feel like these are all dangerous reasons.

Firstly, if youíre generating documentation for documentations sake, youíre either trying to please some form of middle management that doesnít understand what documentation really exists for (hint: to help developers develop), or youíre wasting time.

Secondly, if youíre documenting methods for intellisense youíre probably missing the point.  See, intellisense and other IDE self-help mechanisms are very good; theyíll display method signatures and method names with minimal fuss, any extra comments you glue on top of every method will either clutter your GUI, or become ignored white noise, potentially leading to that one important comment going ignored as your developers slowly desensitise themselves to reading the human generated ďauto-docĒ garbage.

Finally, if you find that you need to cover your methods in comments because they legitimately donít make too much sense at a glance then youíre falling foul of a different problem: you have code thatís not legible maintainable and clear.  In this case youíd be far better served by ensuring your methods are named well, take logical parameters and have single clearly defined purposes.  In my experience, whenever somebody says that they need to comment their methods because the method is unclear, they really should be refactoring, not documenting.

Please DONíT bury your code in comments, just keep it all readable ok?