A girl at work asked me yesterday about whether or not encoding a variable’s type into its name — aka Hungarian Notation — was a good idea (she’s a designer who secretly wants to be a developer). I thought I might have written an article here before about it, but it seems I haven’t, so here goes.

Encoding the purpose of a variable into its name is a good idea. For example:

countries (plural = a collection of some sort)

This is just common-sense good naming.

On the other hand, I think encoding the variable’s runtime type into its name is brain-damaged — it usually doesn’t help much and just decreases code clarity. For example:


I don’t think prefixes like this add any real value at all, because you could probably guess what type they are from their names and context in which they appear. Therefore they are simply clutter.

If you need them, however, then that suggests to me you have either 1) poor variable names that fail to properly explain their purpose or 2) your methods are too long and need to be refactored. Either way, fudging variable names so you can remember what type they were declared as 300 lines earlier is not the right answer, and will probably make your code even less readable.

The difference between these two naming styles is officially known as apps vs systems Hungarian notation. Joel Spolsky has a good article on the difference and how one became perverted into the other here.

June 24th, 2009 | 6 Comments

Traditionally, it’s always been standard practice for programmers to wrap long lines of code so they don’t span more than 80 characters across the screen.

This is because, back in the bad old days, most computer terminals could only display 25 rows of 80 columns of text on screen at once. Any lines that were longer would simply trail off out of sight. To ensure this didn’t happen, programmers split up long lines of code so none of them exceeded 80 characters.

Today, however, it’s pretty unlikely that you or anyone will still be writing code on an 80-column-width terminal. So why do we keep limiting our code to support them?

The answer, of course, is that we don’t. An 80 character limit has no relevance any more with modern computer displays. The three-year-old Powerbook I am writing this post on, for example, can easily display over 200 characters across the screen, at a comfortable 10 point font size. That’s two and a half VT100s!

The reason this standard has stuck around all these years is because of the other benefits it provides.


Long lines that span too far across the monitor are hard to read. This is typography 101. The shorter your line lengths, the less your eye has to travel to see it.

If your code is narrow enough, you can fit two files on screen, side by side, at the same time. This can be very useful if you’re comparing files, or watching your application run side-by-side with a debugger in real time.

Plus, if you write code 80 columns wide, you can relax knowing that your code will be readable and maintainable on more-or-less any computer in the world.

Another nice side effect is that snippets of narrow code are much easier to embed into documents or blog posts.


Constraining the width of your code can sometimes require you to break up lines in unnatural places, making the code look awkward and disjointed. This particular problem is worse with languages like Java and .NET, that tend to use long, descriptive identifier names.

Plus, the amount of usable space for code is also by impacted by tab width. For example, if you’re using 8-space tabs and an 80-column page width, code within a class, a method, and an if statement will already have almost a third of the available space taken for indentation.


Why 80? At work, my current project team uses a 120-character limit. We’ve all got 24″ wide-screen LCD displays, and 120 characters seems to be a good fit for our .NET/Visual Studio development environment, while still leaving ample whitespace.

There are a few factors you should think about, however. The average length of a line of code depends on what language and libraries you’re using. C generally has much shorter identifier names, and subsequently much shorter lines than, say, a .NET language.

It also depends on what sort of project you’re working on. For private and internal projects, use discretion. Find out what works best for your team, and follow it.

For open-source projects, or other situations where you don’t know who’s going to be reading your source code, tradition dictates that you stick with 80.

Another possibility is to make the limit a guideline, rather than a concrete rule. Sometimes you might not care if a particular line continues out of sight. A long string literal, for example, isn’t going to cause the end of the world if you can’t see the whole thing on screen at once.

It may sound pedantic, but if you do decide to use something different, make sure everyone knows the rule, and obeys it. When there are unclear or conflicting rules, chaos ensues. You can end up with hilarious games like formatting tennis, where every time a developer works on a piece of code, they first waste time reformatting the whole thing to reflect their own preferred coding style.

Why bother?

Some of you might wonder why anyone would worry about such trivial details like the length of a line of code. And that’s cool. But, if like me, you believe that code isn’t finished until it not only works well, but looks beautiful too, balancing style with practicality is very important.

May 31st, 2008 | 25 Comments

When prototyping new code I often leave a web browser with thesaurus.com open in the background. It may sound pedantic, but I sometimes find it very useful when deciding what name to use for a class, or what verb to use for a method name. Well-versed code is easy to understand; each class’s name defines its role in the application, and each method’s name describes what the function it performs.

One bad example, which has bugged me for a long time, can be found in Visual Studio. Visual Studio can automatically generate a method stub for you to handle an event. These methods are named after the object that raises the event, and the name of the event, with an underscore between them.

For example, to handle the Click event of a button called SaveButton, the following method stub would be generated:

void SaveButton_Click(object sender, EventArgs e)

This method’s name describes the circumstances under which it gets called, not what it actually does. Methods are supposed to do things. Just because it’s an event handler doesn’t mean the rules no longer apply. Where’s the verb here?

I would propose changing it to generate code that looks like this instead:

void HandleSaveButtonClick(object sender, EventArgs e)

This example is just as consistent (in fact it actually conforms a lot closer to the .NET naming guidelines), and it describes what the method does — it handles a SaveButton Click event.

March 10th, 2008 | 1 Comment

Coding conventions and style is probably programmers’ most fiercely-contested topic, and also the least-important. At the end of the day, as long as the compiler can read your code, and you can read your code, you’re fine. But consistency is good, so many organisations have rules on what their code should look like. These rules answer questions like, do braces start on their own line? Do we prefix private class members? Do we use CamelCase or underscores to separate words? And other such matters of great importance.

Deciding on these rules can be quite a nightmare, as everyone has their own personal preferences which they believe are superior. A lot of arguing can ensue. When deciding on what coding conventions to use, good standards can be found with:

  • The language’s authors
  • Application frameworks and libraries that you use a lot
  • Respectable groups like the GNU project or Mozilla

Bad conventions come from:

  • Other languages
  • Long-standing tradition and sacred cows
  • Other vendors’ implementations
  • Non-programmers

My best recommendation is simply to go with the flow and use whatever style is recommended by your language’s authors and tools. If you’re writing a program in C, use K&R. If you’re using Java, use Sun’s Java conventions. If you’re writing C++ with Qt or some other framework use their standards, otherwise use the STL’s. For Microsoft T-SQL use the style generated by their SQL Server client tools. If you’re writing .NET code it should look the same as the Base Class Library. There is nothing wrong with these standards, and any deviations will simply require extra work to implement, like changing defaults or modifying generated code to match your company’s non-standard standards.

November 21st, 2007 | No Comments Yet