Constantly letting down my variables

As it turns out I’ve been doing everything wrong. Well, maybe not everything, but at the very least I’ve been declaring variables incorrectly.

There are actually three different variable types in JavaScript, var, let, and const. I’ve been using var exclusively and it’s actually bad practice. So what’s the difference between each and which should I be using when?

const

Where at all possible you should use const. Unsurprisingly const is short for constant and without going into to much detail that means it’s something you know will not change. You won’t be able to use this all the time obviously because a lot of the time you need to vary the content of variables. It’s always good pratice to minimise mutability in your code and const is the ultimate example of that.

let

This is how most of your variables should be declared the majority of the time. The strength of let variables is their scope is limited to the block level. For example:

let numberOfPowers = 1;

if (numberOfPowers === 1) {
  let numberOfPowers = "1 more power than Batman"
  console.log(numberOfPowers);
}

console.log(numberOfPowers);

In this example we have two variables named the same thing, but because we are using let their scope is limited to different parts of the code so they don’t collide. So in the console, we’d see both “1” and “1 more power than Batman”.

var

This is the option you should use least often and that’s because of its scope. Unlike let, var has a very wide scope. This is either the function it’s inside of, or if it’s declared outside any function, global. Obviously, that’s not ideal because it creates a greater opportunity to have your variables collide, especially as your projects grow in size. So to revisit our example with var instead of let:

var numberOfPowers = 1;

if (numberOfPowers === 1) {
  var numberOfPowers = "1 more power than Batman"
  console.log(numberOfPowers);
}

console.log(numberOfPowers);

This time the console will only read 2x “1 more power than Batman”. This is because having a global scope means we are writing over a single global variable rather than creating two different variables with different scopes but the same name.

I can see when you’re learning why this concept might be more of an intermediate level concept. Scope can be a bit tricky to get your head around. At the early stages of learning it’s probably better to focus on core concepts rather than nuances like this, but as your skills grow I think this is an important practice to do with variable declaration.

How to write modern JS

So you’re learning JavaScript (JS), cool. Putting all this effort in, you’ll want to be learning the modern usage of the language right? Time to get strict.

“use strict” is something I recently stumbled across, and it seems like a really important thing to be using. So much so that I’m a bit surprised it hasn’t been mentioned in the course I’m doing. As it turns out, JS is full of legacy thinking. In an effort to keep new versions of the language compatible with older versions, much of this legacy thinking was/is retained. Obviously this limits JavaScripts ability to overcome its past and improve as time goes on.

Evidently, in 2009 a decision was made to start to modernise JS with the release of ECMAScript 5 (ES5). This meant breaking compatibility with older version of JS if you decided that was what you wanted to do. This is where “use strict” comes in. To enable this “modernisation” you include “use strict” at the top of your JS files like this:

"use strict";
// code below this will be implemented the modern way
...

Since it’s been 10 years since that decision was made, all modern browsers now support ES5. So unless you need to support browsers before the dawn of IE10 then you should be turning strict mode on for all of your JS development.

This of course begs the question, why? Well, aside from staying current with the language, there are also a number of practical benefits:

  1. Modern JS throws errors on things that where previously ignored. This helps you write better, more secure code
  2. It can improve the performance of your code, sometime significantly. Sometimes the code itself is identical and you just get a free performance boost, nice!
  3. It prevents some syntax being use that future version of the language are likely to use. AKA it future proofs your code

So from here on in, I’m going to be using strict mode exclusively and only avoid it when a situation presents itself that I can’t.

As always MDN is a good source of information on both strict and sloppy mode. Now go forth and write strict code!

Optimising C# scripts in Unity 🏎

C# logoThe more I create C# scripts in Unity the more I learn about optimising those scripts. With code there are 100s of ways to solve a problem, not all of them efficient, so learning to check your codes performance seems like a must.

Things to look for

So far I’ve come across a few simple things to look out for on the projects I’ve been coding. I’ll post more as I come across them in future.

  • Anything that’s called every frame creates consistent load on the CPU, GPU or both. If what’s called is inefficient or large it will have a negative effect on frame rate. In VR this is particular bad given low frame rates can make your user physically sick. Be sure to look at what’s in the Update and FixedUpdate methods and do your best to optimise the code as much as possible.
  • Working on mobile we will almost always be maxing out the graphics capability of the device. This effects the performance of the Update method. On the other hand FixedUpdated runs in sync with Unity’s physics engine. This will make sure your physics will be the most accurate and consistent. FixedUpdate is called every “physics step”, so is regularly used for adjusting physics (rigid body) objects. Make sure you always put your physics code in FixedUpdate.
  • Avoid using GameObject.Find. It basically requires the system to cycle through all of the GameObjects in the game to find the right one, which obviously is expensive for the CPU. If you know what object we are using ahead of time, define the object at the top of the script and reference it that way. GameObject.Find is useful for testing out ideas, but that’s about it.