The Data Asylum

Improper uses of Booleans causes headaches for people who are reviewing your code. Lets take a look at some good, and not so good uses.

Don't be negative

if $notLoggedIn then

Looks simple and readable right? Wrong. It's one step away from being misused.

if ! $notLoggedin then

Not not logged in. Double negatives are a gotcha in language and coding and should be avoided. Fortunately the solution is an easy one. Remove the negative prefix (such as not, doNot, dont) from the variable name.

if $loggedIn then

if ! $loggedIn then

Hide Literals

if $hidden == false then

Is it really necessary to compare the variable to false?

Imagine this conversation. You are at Subway and they ask you

"Would you like your sandwich toasted?"

Would you reply with

"Toasted equals false"
  Or
"Not Toasted"

Avoid comparing with a literal true or false. The correct way to express this is :-

if ! $hidden then

A Boolean Flag?

if $reportFlag then

$reportFlag is a little vague. In this case it is determining if an object is included in a report. So if $reportFlag is true, does that mean that the object is included or excluded? If you have to ask yourself the question then you have already failed and need to rethink what this variable should be called.

if $report then

This is okay as long we are using the word 'report' as a verb. "If we report this then" is how you would read this. Some people may not be able to make that leap so if you want to be more precise you could make it :-

if $includeInReport then

Summary

So to sum up, these three things will go a long way to making your code readable.

• Remove the negative prefix (such as not, doNot, dont) from variable names.
• Avoid comparing with a literal true or false.
• Avoid vague terms like flag for Boolean values.

Consider these ideas when choosing

• Variable names
• Object properties
• Database field names
• Method or function parameter names

Anything Else?

Is there something i've missed? A hole you could drive a double-decker bus through? Leave a comment below.

The Bad Code Offsets project is an attempt to get programmers to put money into open source software. We may not be able to change the bad code we have written. Instead we can buy an offset that goes towards creating more good code.

Bad code lives on well past the time we inflicted those bad lines into the global code base. Applications continue to live their lives serving businesses, consumers and the global community at large. Bad code weakens the utility delivered by these applications causing business loss, user dissatisfaction, accidents, disasters and, in general, sucks limited resources towards responding to the after effects of bad code rather than toward the common good.

They have just made a $500 grant to the GPSd project, which aims to shield developers from the idiosyncracies of integrating each GPS device available.

How often do you use open source software. How often have you contributed, either by submitting code or donating money? My gut feeling is that at least 95% of developers haven't done either. The 10 USD I donated will be going to the Apache software foundation. The apache webserver has been at the base of nearly every project I've worked on and will be for a long time to come.

Glue is what holds your application together. Code needs to talk to databases, Javascript is calling your PHP functions using Ajax. When two systems, or different parts of the same system need to talk to each other, you end up with glue. It (hopefully) doesn't have any business logic. It's used or copied by at least a few different parts of your system, perhaps even in different projects in the same organisation.

Glue code holds things together. The only problem is that glue is not your application. Unless you're developing a framework, operating system or perhaps something that needs plugins, glue is not your strength. There are always exceptions but if you are writing glue, especially the same glue for the 3rd or 4th time, then you're not directly working on the application you are building.

Having said that, your project won't survive without glue. So how do you keep everything together?

• Recognise glue. The first step is to understand that you are now writing glue code and not working on business requirements. For example, say you are writing a script to process files that are uploaded to your server. Discovering the files is glue, the processing of then is specific to your application.
• Standardise across your organisation. Glue may start out as a one off but as time moves on it will become apparent which pieces are worth time improving and which aren't.
• Make it as simple to use as possible. It will need to be understood by a larger group of developers than your other code. Put that extra time into documentation and code beautification.
• Make it as robust as possible. You don't want this getting in the way of your 'actual' work.
• Use 3rd party glue. Someone has nearly always been before you. Wiring your PHP and JS together with AJAX? It's been done. Creating a DB access class? Been there, done that. If you think you can do better your probably wrong. You may write better code, but you probably won't document or test it as thoroughly as an open source project has already been.

In conclusion, you want to keep glue simple and straight forward. Recognise what is and isn't glue in your application. Share the glue you have with every one in your team, and if your brave, the outside world.

The idea of glue is described in Eric Raymond's excellent book The art of unix programming.