XML files successfully read

Screen shot 2010-09-05 at 02.30.16.png

One of the things I used to enjoy about coding was removing “crutches”. Allow me to explain.

Crutches are constants you use to put together a working demo. At some point, these constants need to be replaced with real data, loaded at run-time and editable outside the code.

I’ve just got rid of the first of the crutches. And those were the room width, depth and height constants, which are now being read out of an XML file. I’m also being sensible and sending more status output to the debug console. When I used to code in the early to mid 90s, I got my team to use an awful lot of assertions. I’m not sure how I feel about those, or exceptions now. It’s probably useful (I learned the method from McConnell’s seminal “Writing Solid Code” of course). Assertions really do make the code look a mess, but they are very useful and catch a lot of bugs.

What methods do you use nowadays to code defensively?

3 thoughts on “XML files successfully read”

  1. An incomplete list of tips from me:

    – avoid nested if statements, or complex combinations of && and || operators, or anything which reduces readability

    – space code out a lot (I always open and close { } on a separate line), indent fanatically, and favour longAndDescriptiveVariableNames. I want to be able to return to my code years later, and read it like English as much as possible.

    – favour small, ‘punchy’ methods, switch statements, make extensive use of the ‘continue’ operator inside for loops for cases which fail (eg, if you’re looping through a list of objects instead of doing if (object.passesTest) { .. consider doing if (object.passesTest == false) continue;

    – personally as ‘lone wolf’ I don’t obsess about get/set methods in objects, preferring just to make a member public. I don’t want to bloat my classes with a load of ‘noise’.

    – don’t worry too much about optimisation until its required, favouring habitability and readability over all other properties of code (of course, I’ve been doing this a while, including on crappy mobile platforms, so I tend to instinctively avoid anything too horrendous in the first place).

    – wherever practical, generalise code into utility classes, and share them between all my projects, so you write as little new code as possible with each new project (this is actually the most powerful defensive technique of all, but it obviously doesn’t help on your first project), but..

    – wherever practical, use other peoples’ mature, open source, well-supported libraries to do things for you, instead of trying to reinvent the wheel each time!

  2. Oh yeah, also.. just looking at your XML example in the image above – couple of things I’d suggest:

    consider whether it wouldn’t be neater and easier to do:

    A room can only have one name, one version, one width and height, so they should be attributes of that tag, rather than children I reckon.

    Also, as a general rule, I try to avoid using width, height, depth as names – I much prefer sizeX, sizeY, sizeZ, or similar – because these seem more descriptive, and also (crucially) it’s much easier to copy and paste and edit them (carefully of course!)

    And I think you should store your room block data in a big CSV string. So once you’ve defined the dimensions of the room, just store the block-ids in a pre-determined order, so you end up with “0,0,0,3,4,10,0,10,10 … “. I reckon even for quite sparse rooms, this will end up being less data to store in XML, and much quicker to parse (and the read/write code will be simpler and tidier).

    Oh yeah, and you should definitely store Blocks as just ids (integers) and then have a separate file which defines them, i.e:

  3. balls. Of course I can’t type XML into comments. Doh!

    I meant – swapping brackets to [ ] )

    [ROOM name="Ramadan" version="0.0.1"]


    [BLOCK id="0" src="cube64x64.png" /]

Leave a Reply

Your email address will not be published. Required fields are marked *