5 rules of variable naming.

When I was at uni some 10 years back now, I remember one of my lecturers telling me not to make variable names too long because you would get "pain in your fingers".

Well, rule #1 goes against that advice:

1. Make your variable names long and descriptive
Visual Studio has IntelliSense, Eclipse has its own code completion, and I'm sure whatever IDE you're using can finish your variable names off for you, too. Using long names prevents the ambiguity of short or cryptic names.

2. Put units in your variable names
If you are writing an engineering application you are going to be using variables with units. Embed the unit name in the variable, for example, distanceInMM.

3. If you are using Camel Case, don't capitalise commonly hyphened, or combined words.
Let me explain.

Callback is normally spelt as one word. So, pretty please, don't call your variable callBack.

4. Never, ever use the variable name temp. The only perfectly valid exception to this rule, is when you're writing a swap function.

5. int i is perfectly valid in a small loop. I've met programmers who would crucify me for saying this, but when your loop is half a dozen lines of code long or less, int i is perfectly valid as a loop counter. It's so widely used, it's almost expected.

Coding is dead, long live unit testing.

There are IDEs that can generate unit tests for your class once you've written the basic class stub. Or, they'll generate your class stub for you from the unit test code.

But a unit test suite should be written to cover all of the requirements in the requirements specification. It should be the contract of what is being developed.

So, if you've gone to all this effort to create a fully specified unit test suite, why should you then double your effort to write some more code to fulfil these requirements?

Couldn't something do this for you?

Like, a genetic software generation algorithm?

Life ROI

I enjoy DIY.

I'm not one for fitting a new central heating system or building a new conservatory, but I will paint a wall or two. I do it not only because it's rewarding but because I'm hoping it'll add some value to my new house.

But is it the best Return On Investment for my time?

Would it be more cost effective for me to spend my time reading a programming or management book and negotiating a pay rise for my additional knowledge whilst, at the same time, paying a professional decorator to paint my walls?

I'm still unsure how to measure the value gained from reading a book. Or, for that matter, how to measure the pride from knowing that the house is looking better because of me.

Further hat tipping

Richard Dare has already written several excellent articles on game design, I eagerly await his first blog post.

Welcome to the world wide weblog Trickster!

OSA

May I just tip my hat to the work of Andy Budd on the Operation South America website, he's come up with a great design and made some fantastic use of flash.

What a cool robot.

We've just found out that the robot we've been working on is a MacRobert award finalist.

I'd love to win it, but there's some really tough competition.

Brake Lights: A Usability Study

Have you ever been navigating through the front end menus of a PS2 game and gone off to get a cup of tea only to come back and think, "Which menu item did I have selected?"

No?

That's because console developers have to adhere to strict standards, know as TCRs and TRCs, that describe in precise detail how a front end menu should behave.

For example, Sony state that the selected menu option - which could be an icon or a word - must be coloured differently to the rest of the menu. But if there are only two menu items on the first menu you encounter, how do you know which colour is the selected colour and which is the unselected?

So a colour change alone isn't enough. Because Sony et al know this they also state that there must have some sort of animation of the selected item - some sort of distinguishing feature.

So what has this got to do with car brake lights?

On old cars, the brake lights sometimes share the same housing as the rear lights. The problem with this is the rear lights just look a bit brighter when the brakes are applied. If you happen to look away just before the brakes are applied, then when you look back again it's often difficult to tell that the car is slowing.

Or, to put it another way, there is no distinguishing feature to show that the brakes are applied.

So, in 1998 the EU stated that all cars must have a centre brake light. A distinguishing feature that allows other drivers to instantly see that the brakes are applied. (Incidentally, the EU took a whole 12 years to catch up with the America!)

Make your distinguishing features blatantly obvious and your users will thank you for it.

Mobile broadband

I want a fully blown, always on, pay-per-month, unlimited usage mobile broadband.

I want a device, much like a mobile phone, that acts as a mobile broadband server and a mobile wifi router.

I want to sit in my car with this mobile device in my pocket and for my internet car-radio to serve music through it. I want to listen again to Zane Lowe on my way to work in the morning.

I want my in-car GPRS system to auto-detect the mobile internet server and to tell the world that I'm not moving very quickly, that I'm stuck in traffic. Or to divert me off the M25 when the GPRS' traffic information server tells me that there are plenty of others parked up on it.

I want to sit in the park, open my laptop and instantly be able to access the internet through this device.

And I want this for £15 a month without the worry of data limits.

Is all this too much to ask?

How is refactoring like throwing out the rubbish?

In these green days, you no longer just throw out your rubbish. You rinse, separate, sort and then throw.

A process, not dissimilar to refactoring.

Some code goes into your grey, household waste bin. This is the stuff that was written before the scope of the project was finalised. It has normally been written quickly, doesn't always fit the spec, and is often bug-ridden. It can't be recycled. Just bin it.

But hopefully most of your code will end up in the blue bin. This is the stuff that can be re-used - sometimes with no changes - but usually needing a bit of washing and sorting.

You can help the process by building modular code with good clean interfaces early on in development.

In this green age, filling your blue bin and recycling old code as much as possible is essential. And this can be helped by building modular code - with good, clean interfaces - early on in the development.

Has my article been read?

So you've written a website with pages of search-engine-friendly text and you know how many unique visitors you are getting from your weblogs. But how much of your perfectly crafted prose is actually being read?

You could argue that with the weblogs of a site containing many small pages linked together you would have that information. But whenever I navigate to an article that has half a dozen pages, I know it certainly frustrates me.

So if you are writing long pages (ie, with more text that can fit on the screen in one viewing) you are going to need a way of working out whether people have actually bothered to read all that you are writing.

And once again, Ajax comes to the rescue.

Using javascript it's possible to figure out the position of the scroll bar. And using Ajax it's easy to tell the server about this position.

You could even write some server-side code to distinguish between a quick browse down the page and a full-on page read.

Engineering Problems on Large Software Projects

Size matters.

If you are on a large software project, you are going to face a bunch of problems that you just won't see on small developments.

And by large projects I mean multi-programmer developments based on a library of modules written over a number of years.

I said, "based on a library of modules". If you don't make your code strictly modular, you've already failed. That isn't always easy, especially when it's the day before a deadline and it's far quicker to bodge in a fix.

Given that you have a bunch of modules, with different versions of them used over several products or versions of the product; maintaining a formal build process is essential. Builds should be numbered or labelled and it should be trivial to reproduce any previous build from you version control system (you do have a version control system, don't you?)

Some formal structure to record who has what build is also needed.

Code re-use generates code as structural patterns are needed to ensure your new module can communicate with the existing functionality.

And with all this extra interfacing code, finding the guts of a particular function or class becomes a real issue. Although Google intranet search tools can certainly help here.

If you've only ever hacked together 2-day projects in your bedroom, these issues will be alien to you. Anyone who's worked in a real software house should be familiar with most if not all of them.

The new SI units

"Have you heard? The smiths won the lottery last week and the house they're looking to buy has a garden the size of 2 football pitches!"

But a football pitch can vary in size from 4,050m² to 10,800m².

And new mp3 players are often quoted as being able to store a certain number of songs, for example the 1Gb iPod shuffle can store 240.

But is this 240 average 3½ minute radio edits?

Or 240 20-minute drum and bass epics?

Or does it even matter?

Using a commonly known "thing" means far more to the average user than an exact figure. Approximating information is a good thing.

If you're only presenting information with 1 or maybe 2 significant figures, do you really care how accurate the unit is?

Company Culture

We hear about company culture all the time, but until you've worked in a few companies it's hard to understand how two software development houses can feel so different to work at.

The Team

A team based company will normally separate groups off into their own little rooms or sections of the open plan office. There is likely to be a hierarchical structure to each team with a one or two Chiefs and then many Indians.

Games companies typically tend to have this structure as game building is very much a large team activity, especially with the modern consoles and large budgets that accompany them.

The Consultancy

Consulting companies tend to treat staff as experts in their field. The company understands that if their staff can't solve a problem, they'll find someone who can.

In this type of company you'll be given freedom to work and you'll be treated like an adult. But you may be left to just get on with it.

This type of company would tend to employ someone with experience rather than a fresh graduate and the office is likely to be fully open plan.

The Start-up

Small, agile, and with time to market a priority, start-ups can be fun, energetic and hectic. If you're lucky enough to have an office you'll be sharing it with just a handful of others, some of whom may have experience but all of whom will be passionate about what they do.

Expect to roll out core software on Monday.
Explain it to your client on Tuesday.
Fix a bug in it on Wednesday.
Deploy a fixed version late Thursday evening.
And spend Friday afternoon in the pub with the directors celebrating a great week.

Don't be surprised if you get asked to help build the company website or install a company-wide version control system as the company will be too small to have a dedicated expert in that field.