MOAR CODING TIP! AND LOTS OF CAPS!

Yet another tip from your friendly neighborhood dev.

By Corey Adler (ironman84), professional software developer

(With many thanks to my boss, John Ours.)

I knew it would eventually come to this. I knew I would inevitably have to deal with this issue, but I was hoping to put it off a bit longer. The thing is, I painted myself into a corner with my last post.

Well, here goes:

Always, always, FRAKKING ALWAYS declare your variables.

I don’t care if you’re using a language that allows for dynamic typing.

DECLARE. YOUR. VARIABLES.

Why am I so passionate about this? It probably has to do with the fact that I’ve had to take a look and fix code in script files where variables were not declared. Those were some of the most difficult tasks in my career, simply because it made it harder for me to keep track of everything going on. It might be easy and simple for you to describe what each of your variables is doing, but what about the next person that’s going to take a look at it? As a programmer you always have to think not just about what you’re doing right now, but what might happen days, months, or even years from now.

So what about someone, like yourself, who is not a professional programmer, who is just playing around with the code? Wouldn’t that argument work in your favor (since no one else will be working on it)? NOPE! Because that next person could easily be you, years later, looking back over at some piece of code. Sadly, you can’t even make the assumption that you, who wrote the code, will still have some idea what that code does when you go back to look at it.

The best thing for you to do is to assume that the next person to look at it won’t have any idea about what’s going on and needs you to help explain things. The reason you should declare the variables is to help with the self-documentation of your code for future use. It’s a great practice to get into, and no professional experience is needed.

That’s as far as styling goes, though. The primary reason to always declare your variables (as well as why you shouldn’t just declare them at the top of your file), is because of a concept called implicit scope. Implicit scope is the idea that one should only declare their variables as they happen to need them. The benefits of this approach are twofold. First, it reduces the number of variables in your program that only appear in certain contained blocks of code. For example, let’s say that you have a variable that you only use inside of a for-loop. Instead of having that variable taking up space (both in your file and in memory) for the whole length of the program, you have that variable declared and used only in that for-loop. That way no one looking at the code needs to worry about other locations that use that variable since it’s clearly contained within a specific block of code. Second, it makes it easier to debug your code should the need arise. When you see a variable declared right before its first use in your program, you know that it hasn’t been used previously.  If you haven’t declared your variables, though, or you’ve declared them at the top of the file, someone (including you) who goes to look at the code later will need to check to see if that variable is being used anywhere else prior to that location, which can waste a lot of time and be a drain on one’s memory.

A third reason to declare your variables involves something in programming called coercion. Coercion is defined as automatically forcing one of the operands in a function to that of another type at runtime. Here’s an example of implicit type coercion, using JavaScript:

[ ] == 0; // result is true
0 == "0"; // result is true

So why, exactly, is coercion a bad thing? First of all, it requires each variable that you create to take a larger chunk out of memory than would normally be required. In statically typed languages, like C#, each different variable type is allocated a certain, fixed amount of memory, which would correspond to the size of the maximum values for those types. With coercion, all variables are treated the same, and are allocated the same amount of memory, sometimes way more than is necessary. All of this can add up in your application, potentially causing it to run slower.

A fourth, and probably more understandable reason for people not as well versed in coding as you, are the insanely weird behaviors that can occur by using coercion. Take this extreme example that I found at http://g00glen00b.be/javascript-coercion/:  Insert the following into the address bar of your Web browser (and replace the “javascript:” at the front if you have a browser that automatically removes it when copy-pasted):

javascript:alert(([]+[][[]])[!![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+(typeof (![]+![]))[!![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+([]+!![])[![]+![]]+([]+!![])[![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]])

The result of this is an alert box with the name of the person who wrote the post at the aforementioned link. All of this is only possible through coercion. Let’s take another, simpler example of the weird behaviors that can occur when you allow coercion to happen, found at http://whydoesitsuck.com/why-does-javascript-suck/ :

var a = "1"

var b = 2

var c = a + b

In a case like this, what would you expect the result of c to be? If you think it should be 3, then you’re a victim of coercion. The same goes if you think it will be “3” (as in the string value). In actuality, the value populated in c is 12. Adding a + sign to a (as in “+a + b”) will give you back 3 (as a number; not a string). Or how about the following example:

16 == [16]       

16 == [1,6]      

"1,6" == [1,6]  

So what do you think? The first one could be true, because they both contain 16, but it could be false since one is an integer and the other is an array. The second one doesn’t look right, but maybe that’s how an array of integers is expressed when printing them on the screen. Or the third one, which also doesn’t look right, but could be right for the same reason the second could be. The truth, in order, is true, false, and… true. WHAT THE HECK IS UP WITH THAT? It turns out that that is actually how JavaScript translates an array (into that string) and then comes back as true, since they now match.

One final reason for avoiding both coercion and the itch to not declare your variables involves programming architecture. Programming languages typically rely either on interpreters to translate the code to be run (like in Java), or on compilers that do the same. What happens when your code is run is entirely dependent on those interpreters or compilers. Those things, in turn, can be highly dependent on the architecture of the computer that it’s being run on. Slight changes in either the compiler or in the architecture could drastically change the result of the program, even though it’s still the same code being run. What happens if, at some point down the line, someone makes an adjustment to the coercion system? How much code would that affect? Considering the ever-changing nature of the IT world we live in, that’s not a trivial concern. It’s also not a remote possibility either, with JavaScript due to receive the upgrade soon to ES2015. What will your code do when it gets upgraded?

So there you have it: ALWAYS DECLARE YOUR VARIABLES, EVEN IN DYNAMICALLY TYPED LANGUAGES. In the words of the Governator:

No, wait, that’s not right. Ah, here it is:

I’m finished ranting. Let me know what other topics you think I should touch on in the comments below, or feel free to message me on thwack. Until next time, I wish you good coding.