cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

MOAR CODING TIP! AND LOTS OF CAPS!

Level 9

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.

xkcd_comments.png

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:

ahnold1.jpg

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

ahnold2.jpg

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.

12 Comments
MVP
MVP

Very good.  Another aspect of scope regarding variables declared at the top of the code is the global nature.  Now you have to know

where it is being modified so that you know what it should contain.  Don't use same named variables in functions or subroutines unless you know

for a fact that they are local to the subroutine or function.  Otherwise you can get mysterious unexplained results that are fun to locate.  This is a topic

unto itself.

For those Reboot! fans out there:

Dot, running through a prison filled with loose dangerous binomes:  "And don't forget to declare your variables!"

Bob, frantically programming an unfamiliar interface to stop the prisoners:  "Hey, I'm not THAT basic!"

Level 14

Well done! Got me to thinking and put together a list of things I need to look at!!!

MVP
MVP

Nice write-up. I couldn't agree more. Declaring variables as needed is a good practice and something new coders can easily make a habit of right out of the gates. Also, add notes....... No one will understand what logic was going on in your head when you write something.

And yes...I've looked back at old code and wondered what I was thinking myself.

Level 9

So true. And might I mention the necessity of formatting programs/scripts/whatever in a neat, human-readable manner (i.e. standard indenting and bracket practices) and properly documenting one's variables and code. One of the most memorable projects I had in a programming class involved the teacher giving us a broken, poorly formatted, poorly documented program and telling us to fix it. It was a rather time-consuming, patience-testing project to complete. Also, might I suggest the advisability of using meaningful variable names where possible?

Level 17

YES!

Always, always, FRAKKING ALWAYS declare your variables  - ironman84

Nice one here!

Level 12

interesting very much

And comments, Comments, COMMENTS.

I had to take over an application from another developer.  The transition was easy because all variables, conditionals and functions were well commented.

Level 9

Yes. This step is crucial.

Level 14

Yes, comments.  Whether coding, scripting, or just writing a long ACL.

(By the way, nice art!  Did you craft it yourself, or find it online?)

Level 12

Nice story about software coding.

About the Author
I grew up in Forest Lake, Minnesota in the 1960's, enjoying fishing, hunting, photography, bird watching, church, theater, music, mini-boggan, snowmobiling, neighborhood friends, and life in general. I've seen a bit, have had my eyes opened more than once, and tend not to make the same mistakes twice. Reinventing the wheel is not my preference, and if I can benefit from someone else's experience, that's good all the way around. If someone can benefit from my experience, it's why I share on Thwack.