Forem: Ron Northcutt

Variables in Javascript: A Comprehensive Guide to Var, Let, and Const

Ron Northcutt — Mon, 22 Jan 2024 08:00:00 +0000

In software, a variable is a symbolic name that represents a value or a reference to a value. It's a way to store information that can be reused and manipulated throughout your program. You can think of a variable like a label or even a sign pointer - it represents the data (which can potentially change) but is not the actual data itself.

I am often reminded of that great scene in the Bruce Lee movie, "Enter the Dragon", where he tells his student that "it is like a finger pointing the way to the moon - don't concentrate on the finger, or you will miss all of that heavenly glory." The variable is important, but what it represents is actually what you care about.

Ok, maybe that's a little bit of a stretch, but you get the idea. Variables are essential building blocks in JavaScript programming, allowing developers to store and manipulate data. There are 3 main ways to declare a variable, and your choice can have significant implications on your code's behavior and maintainability. Many developers just choose one and use it for everything, but that's just lazy and can sometimes cause problems.

Let's explore these three methods of variable declaration in JavaScript: var, let, and const, diving into when and why to use each, along with their respective advantages and drawbacks.

1. `var`: Function-Scoped Variables

In JavaScript, var is a keyword used to declare a variable. It has some specific behaviors that set it apart from other variable declaration keywords like let and const.

Here's what you need to know about var:

Function Scope: Variables declared with var are function-scoped, meaning they are accessible within the function where they were declared (or globally if declared outside any function).
Hoisting: Unlike let and const, variables declared with var are "hoisted" to the top of their containing function or global scope. This means that they are technically available from the beginning of that scope, but their value will be undefined until the code where they are assigned is executed.
Reassignment: You can reassign new values to a variable declared with var.
Redeclaration: In non-strict mode, you can redeclare a variable using var in the same scope without getting an error, which is not allowed with let and const.
No Block Scope: var does not respect block scope (such as inside an if statement or a loop), which can sometimes lead to unexpected behavior. If you declare a variable with var inside a block, it's actually available to the entire surrounding function or global scope.

Because of these peculiarities, and with the introduction of let and const in ES6 (ECMAScript 2015), the use of var has become less common in modern JavaScript, and it's often recommended to use let or const instead for clearer scoping rules and better maintainability.

When to Use

You need a variable with function-level scope.
You are working with older code that doesn't support ES6.
Typically, you should avoid var, but it can be handy in some cases.

Pros

Function Scope: Variables are accessible within the entire function where they're declared.
Hoisting: Variables are moved to the top of their scope and initialized with undefined, allowing them to be referenced before declaration.

Cons

Lack of Block Scope: Variables can be accessed outside the block they were declared in, leading to potential bugs.
Hoisting Quirks: Can cause confusion as variables are available before their declaration.

Example

    function varExample() {
      console.log(x); // undefined, because of hoisting
      var x = 10;
      console.log(x); // Output: 10

      if (true) {
        var x = 20; // Same variable, even though it's in a different block
      }

      console.log(x); // Output: 20, because var does not have block scope
    }

2. `let`: Block-Scoped Variables

So, if we had var, why did we need something else? The reason why the let keyword was introduced to javascript was because function scope is confusing and this led to a number of bugs and errors. let was was introduced in ES6 (ECMAScript 2015) as an alternative to var, with some key differences in behavior:

Block Scope: Unlike var, variables declared with let are block-scoped, meaning they are only accessible within the block in which they were declared (e.g., inside an if statement or a loop).
No Hoisting: Although let declarations are hoisted, the variables are not initialized until the code execution reaches the declaration. Attempting to access the variable before its declaration will result in a ReferenceError.
Reassignment: Like var, you can reassign new values to a variable declared with let.
No Redeclaration: In strict mode, you cannot redeclare a variable using let in the same scope.

When to Use

You need a variable with block-level scope.
You expect to reassign the variable within its scope.
Probably should be your default method for creating variables.

Pros

Block Scope: Variables are only accessible within the block where they're declared, reducing potential errors.
No Hoisting Issues: Variables are not initialized until the code execution reaches the declaration.

Cons

More Limited Scope: Might require more careful planning of where the variable is declared.

Example

    function letExample() {
        console.log(x); // ReferenceError, because it doesn't exist yet (no hoisting)
        let x = 10;

        if (true) {
            let x = 20; // Different variable because it's in a different block
            let y = "I see how it works";
        }

        console.log(x); // Output: 10, because we are in the block for the original variable
        console.log(y); // ReferenceError, because y is block-scoped
    }

3. `const`: Block-Scoped Immutable References

The const keyword, which, like let, was introduced in ES6 (ECMAScript 2015). It has similarities to let, but with some unique characteristics:

Block Scope: Just like let, variables declared with const are block-scoped.
No Hoisting: Similar to let, const declarations are hoisted, but accessing them before their declaration in the code results in a ReferenceError.
No Reassignment: Unlike var and let, once a variable is assigned with const, it cannot be reassigned. Attempting to do so will result in a TypeError.
No Redeclaration: You cannot redeclare a variable using const in the same scope.
Must Be Initialized: A const declaration must be initialized with a value at the time it's declared.

When to Use

You want to declare a variable that should not be reassigned.
You need block-level scoping.

Pros

Immutable Reference: Prevents reassignment, making the code more predictable.
Block Scope: Like let, variables are only accessible within the block where they're declared.

Cons

Not Fully Immutable: Only the reference is constant, not the object itself. If the variable is an object, its properties can still be altered.

Example

    function constExample() {
        if (true) {
            console.log(PI); // ReferenceError, because it doesn't exist yet (no hoisting)
            const PI = 3.14159;
            PI = 3; // Error: Assignment to constant variable
        }
        console.log(PI); // ReferenceError, because PI is block-scoped

        const obj = { value: 5 };
        obj.value = 10; // This is fine because object properties can be changed
        obj = { value: 20 }; // TypeError, reassignment not allowed
    }

Conclusion

In modern JavaScript development, understanding the appropriate use of var, let, and const is crucial. While you can safely plan to use let most of the time, it is important to understand how block scope works so you know when it makes sense.

Use var for function-level scope, mainly when dealing with older code or specific scoping needs.
Utilize let when block-level scope is required, and you expect the value to change within the block.
Opt for const when you want to ensure that the reference to a value stays constant within a block scope.

By carefully choosing the right declaration method, developers can write code that is not only more readable but also more resilient and less prone to errors and unexpected behavior. It is usually better to hit scope-related errors earlier (more strict) than later (less strict).

A Hands-on Guide to Git Rebase & Resolving Conflicts

Ron Northcutt — Fri, 08 Dec 2023 07:00:00 +0000

Goal

By the end of this tutorial, you will have a practical understanding of how to use git rebase to integrate changes from one branch to another and how to maintain a clean commit history.

Want a more information about this image? Checkout the "Understanding Git Rebase" guide.

Prerequisites

Basic understanding of Git
Git installed on your system

Overview

Git rebase is a powerful command that allows you to integrate changes from one branch into another. Instead of merging, which takes all the changes in one branch and merges them into another with a new merge commit, rebase takes a different approach. It replays your changes on top of the branch you're rebasing onto. This results in a cleaner, more linear commit history.

Of course, it's not all sunshine and rainbows - problems do pop up. So, lets take a look at how to use git rebase and also how to deal with conflicts when they arise.

1. Set up a Test Repository

Lets go ahead and create a test repository that we can use to play around with git rebase.

# Initialize a new repository
git init rebase-demo
cd rebase-demo

# Create a main branch for primary development
git checkout -b main

# Create a file and commit it to the main branch
echo "Initial content" > file.txt
git add file.txt
git commit -m "Initial commit on main"

2. Create a New Feature Branch

Now, let's create a new feature branch that we will rebase into the main branch later. We will create a simple file and commit that change to the branch.

# Create a feature branch and add a file to it.
git checkout -b feature-branch
echo "Some feature content" >> file.txt
git commit -am "Add feature content"

3. Make More Changes to the Main Branch

Let's go back to the main branch and make some more changes. These changes are what our rebase will be added to.

# Go back to the main branch and make changes
git checkout main
echo "Another line in main" >> file.txt
git commit -am "Update in main"

Now, you have two branches: main and feature-branch, both with unique commits.

4. Rebase the Feature Branch

Now, the magic happens. We switch to the feature branch, and rebase it into main.

git checkout feature-branch
git rebase master

Wait, is that it? Is it really that simple?

It can be, for sure! Assuming all went well, the commit history will show the feature-branch commits will be on the main branch. Those experienced or very observant developers may have noticed a problem above... we will have a conflict. However, not all is lost. Let's take a look at how you can adapt to this situation and fix any minor problems.

5. Resolve Conflicts

During the rebase, you'll encounter a conflict because line 2 of file.txt is different in each branch. That's ok - no need to panic. All merge conflicts can be fixed with the same basic steps. Here's how to resolve it:

Identifying the Conflict: Git will indicate that there's a conflict. You'll see a message similar to:

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
error: could not apply a669cc6... Add feature content

This message tells you that there's a conflict in file.txt that needs resolution.

Evaluating the status: One of the great things about Git is that you can always ask for a status update to see what is going on and what you may need to work on. Just make a note of the problems to fix and handle them one at a time.

interactive rebase in progress; onto 117fde3
Last command done (1 command done):
    pick a669cc6 Add feature content
No commands remaining.
You are currently rebasing branch 'feature-branch' on '117fde3'.
    (fix conflicts and then run "git rebase --continue")
    (use "git rebase --skip" to skip this patch)
    (use "git rebase --abort" to check out the original branch)
Unmerged paths:
    (use "git restore --staged <file>..." to unstage)
    (use "git add <file>..." to mark resolution)
    both modified:   file.txt

Viewing the Conflict: Depending on how many changes you are dealing with, you may know exactly what the problem is. Alternatively, you can also use git diff to see the changes. Open file.txt in your favorite editor. You'll see the conflicting changes demarcated like this:

Initial content
<<<<<<< HEAD
Another line in master
=======
Some feature content
 >>>>>>> Add feature content

The content between <<<<<<< HEAD and ======= is from the main branch, and the content between ======= and >>>>>>> Add feature content is from the feature-branch.

Resolving the Conflict: Edit file.txt to keep the content you want. For instance, if you want to keep the content from both branches but want the feature content to appear before the master content, you'd modify file.txt to look like this:

Initial content
Some feature content
Another line in master
Save and close the file.

Marking the Conflict as Resolved: After resolving the conflict, mark it as resolved with Git:

git add file.txt

Continuing the Rebase: Once the conflict is resolved and marked as such, continue the rebase process:

git rebase --continue

If there are more conflicts, Git will pause again and let you resolve them. If there are no more conflicts, the rebase will be completed.

6. Check the Commit History:

Use git log to see a clean, linear history of commits, showing that the feature branch commits now come after the master branch commits. Once the rebase is successful, it will be a fast-forward merge, maintaining a linear history.

Conclusion

Git rebase is a powerful tool for maintaining a clean commit history and integrating changes from one branch into another. While it can be a bit more complex than merging, especially when conflicts arise, the resulting linear history can be worth the extra effort, especially in large projects.

Remember, practice makes perfect. Feel free to experiment with git in safe environments (like our demo repo) before applying it to larger projects. Happy rebasing!

Additional Resources

How to Correctly Execute a Loop Synchronously with Javascript

Ron Northcutt — Wed, 11 Oct 2023 08:37:59 +0000

Understanding synchronous and asynchronous operations is fundamental when working with JavaScript, especially when dealing with loops. In this article, we will explore how to run loops synchronously, even when they contain asynchronous tasks.

The Synchronous for Loop

To execute a loop synchronously with JavaScript, you can use the for loop. The for loop allows you to iterate over a sequence of values and execute a block of code for each value. By default, the for loop is synchronous, meaning that each iteration will wait for the previous iteration to complete before starting.

Here's an example of a for loop that counts from 1 to 10 synchronously:

for (let i = 1; i &lt;= 10; i++) { 
  console.log(i); 
}

In this example, the loop starts with i equal to 1 and increments i by 1 each time through the loop until i is equal to 10. The console.log() statement inside the loop will be executed for each value of i, printing the value to the console.

Introducing Asynchronous Operations

However, real-world scenarios might require you to perform asynchronous tasks within your loop, like fetching data from a server. Here's where understanding the synchronous nature of loops becomes essential.

For instance, if you used JavaScript's native fetch method or another API call within a loop, it would not work synchronously by default. Each request would be initiated almost simultaneously, and the responses would likely return out of order.

Making Loops Synchronous with Asynchronous Tasks

If you need to execute an asynchronous task inside the loop, such as making an API call or fetching data, you can use the async/await syntax to wait for the task to complete before moving on to the next iteration of the loop. Here's an example:

async function fetchData(num) { 
  // Simulating an API call
  return new Promise(resolve => {
    setTimeout(() => resolve(`Data for ${num}`), 1000);
  });
} 

async function myFunction() { 
  for (let i = 1; i <= 10; i++) { 
    const data = await fetchData(i); 
    console.log(data); 
  } 
}

In this example, the fetchData() function makes an asynchronous API call and returns the result. Inside the myFunction() loop, we use the await keyword to wait for the API call to complete before moving on to the next loop iteration. This ensures that the loop is executed synchronously, with each iteration waiting for the previous iteration to complete before starting.

Understand your needs

While using async/await within loops guarantees order, it might not be the most efficient approach for all use cases, especially if the asynchronous operations don't depend on the result of the previous one. In such cases, running them concurrently might be more time-efficient. You might also want to use events or even Promise.all() to handle all the results when they are complete.

Using loops synchronously in JavaScript is straightforward. However, when introducing asynchronous operations within loops, it's essential to ensure they maintain the desired flow. The async/await syntax offers a neat way to achieve this, but it's vital to consider the efficiency and nature of the tasks when applying this method.

The Evolution of Git: A Dive Into Tech History

Ron Northcutt — Tue, 19 Sep 2023 16:49:19 +0000

In the earliest days of my career, I never used version control. At that time, Git didn't exist and most version control systems were clunky tools used mostly by corporate engineering teams. I was doing a lot of freelance consulting, so most of my projects were just me working alone. SFTP, occasional backups, and lots of *.bak files worked reasonably well. Still, I lost work or wished I could return to an earlier version after multiple refactors... especially since I was still learning.

When I joined my first team as a developer, I was introduced to "Subversion". This was a whole new world - the ability to see all changes, go back in time, and to safely make changes was great. It changed the way I thought about code. The problem is that it was slooooow. I was working on a large project, and updates took quite a while.

Then, I joined a company as a Sr. Developer, and they were using this new thing called "Git". I wasn't familiar with it, and actually, my first commit to the main branch broke the app in production (cue heart attack)! I had no idea about merge conflicts or how to fix them. However, once I got the basics down, I became a huge fan. It was FAST. So much faster than Subversion, and really much easier to use. With just a few commands, I was fairly proficient, and for more complex things I could easily find help online.

Today, it is almost impossible to learn about software development without learning about Git. For many developers, the command git commit is a daily ritual. It's the heartbeat of countless projects yet, how many of us know the story behind this powerful tool? We've all heard bits and pieces, but let's take a deeper look at Git and how it came into being.

What is Git?

"I'm a very lazy person who likes to get credit for things other people actually do. In the Linux project, I started it, and I'm still considered the central point, but I'm not a good programmer. I'm a good manager. My only job is to say 'no' to people, and sometimes I accept patches and put them into my tree. I wanted a tool where I can do that. That was my only design criteria, and it turns out when you do that kind of tool, you can use it for a lot of other things too."

-- Linus Torvalds

To start with, what the heck is Git? At its core, Git is a distributed version control system (VCS). It lets multiple users track changes in source code during software development, maintaining a history of code changes, and ensuring traceability. It is like a shared digital diary for computer code, allowing many people to write in it while keeping a record of all changes made over time.

But unlike many version control systems that came before it, Git operates on a distributed model, meaning every developer's working copy of the code is also a repository with complete history and version tracking abilities, independent of network access. This means that developers can work locally on their machine, and then sync those changes later. This was a big change in how VCS affects the daily workflow of a developer.

One of Git's key advantages is its efficiency in handling changes. Instead of sending an entire copy of the codebase each time, Git only transmits the differences (or changes) from the last known version. This approach significantly reduces the amount of data transmitted and results in faster sync times, providing a performance advantage, especially for large projects.

The Genesis: Why Was Git Created?

"So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first *kernel* commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I’d seen the problems others had. I’d seen what I wanted to avoid doing."

-- Linus Torvalds

Flashback to 2005. The Linux kernel, an enormous open-source project, used a proprietary VCS called BitKeeper. However, due to a conflict between the community and the company behind BitKeeper, the free-of-charge status was revoked. Necessity is the mother of invention, and this incident paved the way for the creation of a new system. Linus Torvalds, the creator of the Linux kernel, took the reins. He aimed to create a tool that was:

Distributed: Unlike other systems where a central repository was required.
Compatible: The new tool would incorporate as many features and workflows as BitKeeper.
Secure: Ensure the integrity of source code and protect against corruption, accidental or malicious.

So, after a few days of work, Torvalds had a working prototype of Git, and less than a month later, Git was managing the Linux kernel source code. On April 7, 2005, Linus Torvalds made the first-ever commit to Git. It wasn’t a grand feature; it was a simple README file. However, the major version (v1.0) took its time and was released on December 21, 2005. But, what's interesting is that version 2.0 was released almost a decade later on June 1, 2014.

Git got the important things right in the beginning, and that set the stage for a valuable project.

The Showdown: Git vs. CVS

'Well, it was obviously designed for our workflow, so that is part of it. I’ve already mentioned the whole “distributed” part many times, but it bears repeating. But it was also designed to be efficient enough for a biggish project like Linux, and it was designed to do things that people considered “hard” before git – because those are the things *I* do every day.'

-- Linus Torvalds

Concurrent Versions System (CVS) was one of the pioneering tools in the version control domain. So how does Git stand out when compared to such a veteran system?

Distributed vs. Centralized: CVS follows a centralized model, meaning the version history is stored in a central server. If that server crashes without any backups, you lose everything. Git’s distributed approach ensures that every developer has a local copy of the entire history, making it decentralized and significantly safer.
Performance: Git’s local operations, thanks to its distributed nature, means that many tasks are faster in Git than CVS. There's no need to communicate with a central server for every tiny operation.
Branch Management: Branching in Git is a walk in the park. It's an integral part of the workflow. In CVS, branching is a cumbersome process, often avoided due to its complexity.
Atomic Operations: Git operations, like commits, happen atomically. Either they succeed with all changes or fail without any. This isn't always the case with CVS.
Data Integrity: Git uses a SHA-1 hash to manage data, ensuring the repository’s integrity. If something goes awry, it's immediately noticeable.

Notable Performance Improvements in Git

"Just to pick an example: the concept of “merging” was generally considered to be something really quite painful and hard in most SCM’s. You’d plan your merges, because they were big deals. That’s not acceptable to me, since I commonly do tens of merges a day when in the merge window, and even then, the biggest overhead shouldn’t be the merge itself, it should be testing the result. The “git” part of the merge is just a couple of seconds, it should take me much longer just to write the merge explanation message."

-- Linus Torvalds

Git's inception was driven by the need for performance, but that didn’t stop the community from further refining it.

Packed Refs: Instead of keeping every single object (commit, tree, blob) as individual files, Git packs them.
Delta Compression: When packing, Git identifies the differences between versions and stores just the changes.
Garbage Collection: Over time, some objects become obsolete. Git has a garbage collector that removes these unnecessary objects.

These optimizations, combined with many under-the-hood improvements, ensure that Git remains lightning-fast, even for mammoth repositories. Soon after its creation, developers around the world started contributing. Junio Hamano is one such name that stands out. Within just a few months of Git's inception, he took over its maintenance, ensuring it didn’t remain just a side project but evolved into a robust system.

Under Hamano's stewardship and with contributions from developers worldwide, Git was not just about committing or branching. It introduced:

Staging Area: This intermediary area allows developers to format and review commits before finalizing them.
Remote Repositories: With platforms like GitHub and GitLab, remote repositories became a staple, facilitating collaboration among developers globally.
Hooks: Custom scripts triggered by important actions, enhancing Git's capabilities and automation.

It's hard to imagine Git without some of these features today, but think about how innovative and unique these were when they were created.

"Git": An Odd Name with a Humorous Origin

“I'm an egotistical bastard, so I name all my projects after myself. First Linux, now Git."

-- Linus Torvalds

In an email, when asked about the name, he once quipped, “The name 'git' was given by Linus Torvalds when he wrote the very first version. He described the tool as ‘the stupid content tracker’ and the name as (depending on your way): random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of 'get' may or may not be relevant. Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.”

"Git" is British slang for a silly or contemptible person. Silly? Irreverent? Absolutely! But it’s another testament to Torvald’s personality and the informal, community-driven spirit of open-source software.

Git's Journey Continues

From its rapid inception to becoming the backbone of software versioning, Git’s journey is a testament to open-source power. Its success lies not just in its utility but in a global community that continues to nurture and refine it. Git has transitioned from a quick solution to a kernel project hiccup into an essential tool for individual developers and tech giants alike. Its distributed nature, performance optimizations, and robust branching capabilities make it superior to many version control predecessors.

So, as you git push your next big feature or troubleshoot with a git blame, take a moment to appreciate this tool's history, and perhaps, share its story. Because, in a way, every developer using Git today is part of its ongoing saga.

Photo by Yancy Min on Unsplash

Forem: Ron Northcutt

Variables in Javascript: A Comprehensive Guide to Var, Let, and Const

1. var: Function-Scoped Variables

When to Use

Pros

Cons

Example

2. let: Block-Scoped Variables

When to Use

Pros

Cons

Example

3. const: Block-Scoped Immutable References

When to Use

Pros

Cons

Example

Conclusion

A Hands-on Guide to Git Rebase & Resolving Conflicts

Goal

Prerequisites

Overview

1. Set up a Test Repository

2. Create a New Feature Branch

3. Make More Changes to the Main Branch

4. Rebase the Feature Branch

5. Resolve Conflicts

6. Check the Commit History:

Conclusion

Additional Resources

How to Correctly Execute a Loop Synchronously with Javascript

The Synchronous for Loop

Introducing Asynchronous Operations

Making Loops Synchronous with Asynchronous Tasks

Understand your needs

The Evolution of Git: A Dive Into Tech History

What is Git?

The Genesis: Why Was Git Created?

The Showdown: Git vs. CVS

Notable Performance Improvements in Git

"Git": An Odd Name with a Humorous Origin

Git's Journey Continues

1. `var`: Function-Scoped Variables

2. `let`: Block-Scoped Variables

3. `const`: Block-Scoped Immutable References