# Scope

## Scope can be thought of as the area of code in which a variable is visible

#### Please note that the following post is under the assumption that you are not using strict mode. If you aren't sure what that means, don't worry about it for now. Just understand that this is how scope works naturally in JavaScript without strict mode turned on.

#### I also challenge you to run these code examples for yourself as you read through.

Let's look at the following function:

```
function addTwenty(num) {
  var add = 20;
  return num + add;
}
console.log(add);
```

If we ran this code we would end up with a ```ReferenceError```. This is because ```add``` is bound by the scope of the function, and we are trying to access it outside of it's scope. In other words ```add``` is not visible outside of it's scope.

Let's look at another example:

```
console.log(num);
let num = 5;
```

This works as you'd intuitively expect. Since the variable ```num``` has yet to be defined you end up with a ```ReferenceError``` from trying to access a variable that does not yet exist in memory.

However this does not work the same. Declarations made using ```let``` and ```const``` are evaluated at runtime but ```var``` declarations are not, so we end up with ```undefined``` here instead of a ```ReferenceError```:

```
console.log(num);
var num = 5;
```

The fact that the interpreter knows about the existence of these variables before they are declared is due to something known as hoisting.

# Hoisting

## Variable declarations are ***figuratively*** hoisted to the top of it's scope.

What does this mean? It means that due to the way the JavaScript interpreter works, you can imagine that variable declarations are moved to the top of it's scope, and then are ***set*** at the point that you defined them; either at or before runtime depending on if you are using ```var``` or ```let/const```. Sounds kind of confusing, but it's really quite simple. Let's looks at an example.

I want you to notice that this example gives us ```undefined```:

```
console.log(char);
var char = 'a';
```

but this example gives us a ```ReferenceError```:

```
console.log(char);
let char = 'a';
```

Both variables are hoisted, however the difference is that variables defined with ```const``` and ```let``` are evaluated at runtime. Don't believe me that ```let``` declarations are hoisted? Let's prove it really quick for the sake of completion:

```
let char = 'a';
if(true) {
  console.log(char);
  let char = 'b';
}
```

Even though ```char``` is defined in the Global scope, and the local version of ```char``` is declared after our ```console.log()```, we still get a ```ReferenceError```. This means that our local ```let``` declaration is being hoisted and the ```console.log()``` is aware of it, but due to the way the JavaScript interpreter works, we are simply unable to access it at this point. The time in which a ```let``` or ```const``` declaration is not yet available at runtime is known as the ***Temporal Dead Zone***. This can be confusing but it will be helpful to understand in certain debugging scenarios.

Now let's move on.

A variable's declaration is hoisted, but the definition is not. So essentially the following two examples will produce the same outcome:

```
console.log(char);
var char = 'a';
```

and

```
var char;
console.log(char);
char = 'a';
```

One last thing on hoisting for now.

Function declarations are also hoisted to the top of it's current scope, but differently than variables. The function definition is also hoisted with it. 

For example:

```
console.log(squareNumber(4));
function squareNumber(num) {
  return num **2;
}
```

This function will work fine because the interpreter loads the function and it's definition into memory before running through and executing the code.

# Global Scope

## There are different types of scope in JavaScript to be aware of.

Let's start with the Global scope. There are a few different ways to utilize the Global scope in JavaScript.

Let's look at the most simple way:

```
var globalVar = 'I am global!';

function concatString(str) {
  return str + ' ' + globalVar;
}
console.log(concatString('I am hungry!'));
```

We call this Global scope because every other scope within this module has access to ```globalVar```. Notice that the function ``` concatString ``` has access to the ```globalVar```.

Let's take a look at another method of accessing the global scope. Instead of returning the string in concatString, let's set it as a property on the window object. Let's then see if we can access it inside of the logString function:

```
var globalVar = 'I am global!';

function concatString(str) {
  window.concat = str + ' ' + globalVar;
}
function logString() {
  console.log(window.concat);
}

// First we'll call concat string..
concatString('I am hungry!');

// Then let's call logString()
logString();
```

As you can see, variables in the global scope can be accessed by both of these functions.

It is often best practice to avoid setting variables in the Global scope if possible. This is because we often want to avoid other parts of our code accessing and changing values that are used elsewhere in the code. That can lead to some unexpected behavior. Something to keep in mind.

# Block Scope

## let and const are block scoped

What this means is that variables declared using ```const``` and ```let``` are bound to the block they are defined within, but ```var``` is not. Let's take a look at some examples to get a good understanding of what this implies.

Let's look at this ```if``` block. Clearly ```true``` is equal to ```true```, so the code inside of the block will run:

```
if(true){
  var x = 2;
}
console.log(x); // logs 2
```

All of the code within the curly braces are inside of a ***code block*** which has it's own scope. Since ```var``` is not block scoped, it is not bound by the block's scope, and is visible within the ```console.log()```. But let's look at the following variation:


```
if(true){
  let x = 2;
}
console.log(x); // ReferenceError
```

Since ```let``` is block scoped, it is bound by the block's scope and is not visible to the ```console.log()```. Since that's the case, we get a ```ReferenceError``` when attempting to access it. The same would happen here with ```const```.

I want to show you an interesting example using the same example, but let's flip ```true``` to ```false``` and see what happens with hoisting.


```
if(false){
  var x = 2;
}
console.log(x); // logs undefined
```

Since ```var``` is not block-scoped and binding declarations are also hoisted mixed with the fact that ```var``` declarations are evaluated prior to runtime: we get ```undefined``` here. 

The above code can be re-written to look like this:

```
var x;
if(false){
  x = 2;
}
console.log(x); // logs undefined
```

Scope in JavaScript

There are a few things that I believe make an engineer a "Senior" engineer.

1. Asking questions. We grew up on the idea that "there are no stupid questions", which is a nice sentiment, however in the field of software engineering, the fewer questions you have to ask, the better. One thing that really distinguishes a senior engineer from a mid-level is that a mid-level has to ask more questions to unblock themselves than a senior. A senior engineer hits a plateau and then unblocks themselves without having to bother other folks on their team.

2. Adapting to a new code base. A senior engineer is able to onboard themselves quickly into a new codebase. When they receive their first ticket, they are able to traverse the source code, past Git issues/PR's, and Slack messages in a way that will provide them with enough context to complete the task. A mid-level engineer will likely need guidance.

3. Cross-team collaboration. A senior engineer is able to collaborate effectively with Product and UX to keep everyone on the same page. Often times you will find that  these separate disciplines will mis-align on very small requirements as everyone is very busy. In the end, it is up to the engineer to ensure that everyone is on the same page before beginning their work.

4. Ownership and impact. A common mid-level engineer's perspective on work is that they work for the company. As a senior, you view yourself as part of what keeps the company going. This means that when you work on a task, you are aware of the impact of your work. It's often difficult for a mid-level to understand their impact, and thus they can feel detached from owning that particular feature or section of the product.

5. Initiative. It's up to senior engineers to take the initiative to ensure that they "leave the place better than when they arrived". This often means going slightly (but not too much) out of scope to refactor the surrounding code of their current task. This provides a good example of what better code can look like, while also increasing the quality of the code base.

All in all, there are many different perspectives pertaining to what makes an engineer a "Senior Software Engineer", but this has been my thought process as of lately.

All in all, there are many different perspectives pertaining to what makes an engineer a "Senior Software Engineer", but this has been my thought process as of lately.

Memoir #4 - Senior Engineer

## Sometimes it can be tempting to write a bunch of one-liners, and begin abstracting all of your code into functions that allow you to write less code in the future..

However, what would your future self think when they see this code? What if you don't remember what functionality you're abstracting with your cryptic-looking fancy design pattern? Good documentation could remediate that, but what if new developers come into this codebase? Other people think differently, and it can be difficult for people to wrap their heads around your very specific way of thinking.

# In the end I believe code understandability is the key to maintaining a code base for long periods of time.

This is because it leads to less burn-out, and it is much easier for on-boarding newbies onto the codebase. As a developer matures into their career, they tend to realize that it's not all about them. Writing good code is about writing code that is good for everyone who is involved, or who could be involved in the future. Including the end user :)

A Clean and Understandable Codebase Is An Enjoyable Codebase

Memoir #3 - Code Understandability

## Burn-out can occur when you're super excited about a new project. 

The excitement of working on something you enjoy can seduce you into working past your mental threshold. Doing this enough days in a row simply leads to lack of mental clarity, which leads down a road of decline and eventually burn-out. Take a break and reset. Better yet: take breaks right as you're approaching the threshold throughout the day.

If you reach burn-out, take a more serious break. Take a few sick days and binge watch some Netflix. Take walks and let your mind clear. Remember what it's like to be human.

Then get back to it, ***but be responsible***.

Sometimes Less Is More With Heavy Cognitive Tasks

Memoir #2 - Burning Out

## It's impossible to anticipate `exactly` what your software code is going to look like after finishing a new feature. 

That is.. unless you're one of the greatest software engineers in the world. In which case, this memoir should mean nothing to you. But for the rest of us mere mortals, we need to accept that fact. And with that fact in the back of our heads: **we can design our software incrementally in such a way that if the code of "feature 1" is spaghetti, it will not affect the code quality of "feature 2"**. This prevents us from compounding messy code throughout the entire code base. It also allows us the ability (if desired) to revisit features to improve code quality.

Regardless, it is important to take time to think and attempt to anticipate the design of your code before you begin writing. Afterwards, reflect and think about what you could have done to obtain the code quality that you originally anticipated. This cycle will make you a better programmer.

The first of a series of documented thoughts and lessons learned as a professional software engineer

Programming Casually

Follow Me Here

Featured Video

Posts

> Scope in JavaScript

> Memoir #4 - Senior Engineer

> Memoir #3 - Code Understandability

> Memoir #2 - Burning Out

> Memoir #1 - Anticipation Of Clean Code