Skip to main content

Naming Booleans

Naming conventions are one of those little things that can become a big thing when you multiply the scale of the project and/or people involved.

I was just looking through some code yesterday, and I saw a variable with a fairly typical boolean name that followed the format isObjectState

This felt awkward to me, and I took a moment to consider why this is.

In Logic, a boolean is a statement that is either true or false. However, this variable name is written as a yes or no question. It is an easy misconception to equate true with yes and false with no, but though they are similar, they are not exactly the same, and, especially as programmers, we should not treat them as such.

When we expand our variables into full sentences, the awkwardness becomes more apparent. Especially when we insert them into control structures.

Let’s rename our variable to: is this menu item active?

So our control blocks will read:

if is this menu item active?, then highlight it.

while is this menu item active? do something.

Clunky, right?

My preference is to write booleans as a statement. Not only is this more lexically correct, it is more fluid. So our sentence becomes this menu item is active., which I would convert to a variable name such as menuItemIsActive or, simply isActive if it’s an object property. So now our control statements would look like this:

if menuitem.isActive then, highlight it.

while menuItemIsActive do something.

I know it’s just a minor detail, but it makes the code more readable, and is an easy convention to follow. Especially considering there’s zero additional effort required.

What about Hungarian Notation?

There’s a great (if somewhat old) blog post about using Hungarian notation and, in general, (making wrong code look wrong)[http://www.joelonsoftware.com/articles/Wrong.html].

I think Hungarian notation gets a bad wrap, particularly, as the article mentions, because it’s easy to do incorrectly. I know I’m guilty of it. But if used correctly and consistently, I think it is very helpful.

In this case, most of us would prepend a ‘b’ to indicate that the variable is boolean. But as the article mentions, the goal is not to indicate the type of the variable, so much as it is to indicate its compatibility and how it should be used in the code.

I think, in the case of booleans, we don’t need more than the statement. However, if your convention is to prepend a ‘b’, or even if you are keying off of ‘is’ as a prefix, that’s your call. What works best for you, and your team (meaning everyone and anyone who might touch that code), is ultimately what you should be doing.

Comments

Popular posts from this blog

Element.focus() in IE9 running Jasmine tests with Karma

I recently udpated our Jasmine unit tests to run in Karma ; expanding our browser coverage, adding code coverage reports , and using fixtures for testing DOM manipulation . One of my tests kept failing in IE9, but only when I ran from the console. If I attempted to debug in the browser, everything passed. It turns out that IE9 (at least) needed a few ms to catch it's breath before correctly focusing on the starting element. To do this, I just added a 100ms delay before each test ran (Using Jasmine 2.3). beforeEach(function(done){ loadFixtures('myfixture.html'); // Setting focus in IE requires a delay to work correctly! setTimeout(function(){ done(); }, 100); });

Flags vs Vendor Prefixes for Experimental CSS

Google recently announced that it will be switching Chrome's rendering engine to a fork of Webkit, called “Blink”. If you're interested, you can read their blog post about Blink . One of the changes we will be seeing in Blink, is the use of browser flags in place of vendor prefixes . What this means, is that rather than prefixing experimental CSS with -webkit-, -moz-, -ms-, -o-, -khtml-, etc.; We will be required to enable these attributes using a flag in the browser (like the ones currently at chrome://flags). If you ask me, both ways have their advantages and disadvantages. Though, in the end, I lean towards the flags over the vendor prefixes, and here's why: #1 Code Bloat On average, using CSS with vendor prefixes requires writing it 5 times . Every time you use it . #2 Future Friendly Eventually, prefixed code will be replaced by the unprefixed code. #3 Browser Dev Friendly Browsers tend to continue to support the prefixed code, even if it doesn...

Get width and height of a remote image with VB .NET

The Problem I wanted to grab the width and height of an image that was on a remote server. I've done this with PHP, but never in .NET. The Solution I did a little digging and came across this code (slightly modified for my own purposes). Dim request As HttpWebRequest = DirectCast(WebRequest.Create(URL), HttpWebRequest) request.Method = "GET" request.Accept = "image/*" Dim response As HttpWebResponse = DirectCast(request.GetResponse(), HttpWebResponse) Dim s As Stream = response.GetResponseStream() Dim bmp As New Bitmap(s) Width = bmp.Width Height = bmp.Height