Like most developers, I installed a library, called a hash function, stored the result, and moved on. I see a random string like \(2a11yMMbLgN9uY6J3LhorfU9iu.... in my database and assume my user's passwords are unbreakable. I knew it was a hashed password. But what was the \)2a? What was 11? And if I couldn't reverse it, how was my app verifying logins at all?

If you've ever used bcrypt, Devise, Django's auth system, or really any authentication library, you've been protected from these details. That's good engineering. But understanding what's actually happening makes you a better developer, and it explains a lot of things that seem confusing or arbitrary until suddenly they don't.

By the end of this article, you'll be able to look at that string and know exactly what every part means.

Prerequisites

This article is written for developers who have used an auth library before but never looked closely at what it's doing. You don't need a cryptography background. If you've ever hashed a password and moved on, this is for you.

Table of Contents

1. Hashing vs Encryption

2. Why a Plain Hash Isn't Enough

3. Enter Salting

4. Why bcrypt Is Slow (and Why That's the Point)

5. What's Actually in Your Database

6. Wrapping Up

Hashing vs Encryption

Most developers use the terms hashing and encryption interchangeably. They're not the same thing, and the difference matters more than you might think.

Encryption is a two-way process. You take data, encrypt it with a key, and you can decrypt it later using that same key (or a related one). This is useful when you need to retrieve the original value. Storing a credit card number you'll need to charge later, or sending a message that the recipient needs to read.

Hashing is different. It's a one-way process. You put data in, you get a fixed-length string out, and there's no key that lets you reverse it. The original value is gone.

That might sound like a limitation. For passwords, it's actually exactly what you want.

Think about it: when a user logs in, you don't need to know their password. You just need to verify that what they typed matches what they set when they signed up. You can do that entirely with hashes. Hash what they typed, compare it to the stored hash, done. You never need the original.

This is why "forgot password" flows always ask you to set a new password rather than sending you your old one. Yes, sending you your old password over email might be risky but the actual reason is that they genuinely can't retrieve it. If they can email you your original password, that's a red flag. It means they stored it in a way that's reversible, which means it's not properly protected.

Why a Plain Hash Isn't Enough

So if hashing is one-way and irreversible, isn't that enough? Just hash every password before storing it and you're done?

Not quite.

The first problem is rainbow tables. A rainbow table is a precomputed database of hashes for common passwords. An attacker who gets hold of your database doesn't need to reverse the hashes. They just look them up. If your user's password is "password123", its SHA-256 hash is always the same string, and that string is almost certainly already in a rainbow table somewhere.

The second problem is related. If two users have the same password, they'll have the same hash. So if an attacker cracks one, they've cracked all of them. In a database with thousands of users, that's a significant security risk.

Here's what that looks like in practice:

import hashlib

# Two users, same password
password = "password123"

hash_one = hashlib.sha256(password.encode()).hexdigest()
hash_two = hashlib.sha256(password.encode()).hexdigest()

print(hash_one == hash_two)  # True, every single time

The hash is deterministic. The same input always produces the same output. That's useful for a lot of things, but for passwords it creates a real vulnerability.

A plain hash gets you partway there. But it's not enough on its own.

Enter Salting

The fix for both problems is something called a salt. And, no it's not your regular table salt.

A salt is a random string generated uniquely for each password. Before hashing, you combine the salt with the password, then hash the result.

import hashlib
import os

password = "password123"

# Generate a random salt
salt = os.urandom(16).hex()

# Combine salt and password, then hash
salted_password = salt + password
hashed = hashlib.sha256(salted_password.encode()).hexdigest()

print(f"Salt: {salt}")
print(f"Hash: {hashed}")

Now two users with the same password produce completely different hashes, because their salts are different. And because the salt is random and unique, it can't be precomputed into a rainbow table.

Here's the surprising part: the salt doesn't need to be secret. It gets stored alongside the hash in your database, in plain text. That might feel wrong at first. If an attacker has your database, they have the salt too.

But that's fine. The salt's job isn't to be secret. Its job is to make each hash unique so that precomputed tables are useless. An attacker who wants to crack a salted hash has to brute force each password individually, from scratch, using that specific salt. They can't reuse work across users.

That's a meaningful increase in the cost of an attack, even when the salt is visible.

Why bcrypt Is Slow (and Why That's the Point)

Salting solves the rainbow table problem. But there's still a gap. If an attacker has your database and decides to brute force a password, they can just keep guessing. Hash a candidate password with the stored salt, compare it to the stored hash, repeat. With a fast hashing algorithm like SHA-256, a modern GPU can do billions of these comparisons per second.

That's the problem with using a general-purpose hash function for passwords. Algorithms like SHA-256 and MD5 were designed to be fast. That's great for things like verifying file integrity or generating checksums. For passwords, it's a liability.

This is where bcrypt comes in. bcrypt is a password hashing algorithm designed specifically to be slow. Not broken or inefficient by accident, but deliberately, configured-to-be slow. It has a cost factor (sometimes called a work factor) that controls how computationally expensive the hashing operation is.

import bcrypt

password = b"password123"

# The cost factor is set here (12 is a common production value)
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

print(hashed)

Every time you increase the cost factor by 1, the hashing operation takes roughly twice as long. At a cost factor of 12, a single hash might take around 300 milliseconds on your server. That's imperceptible to a user logging in. But for an attacker trying to brute force millions of passwords, it turns a feasible attack into an impractical one.

The other advantage of a configurable cost factor is that you can increase it over time as hardware gets faster. What was slow enough in 2015 might not be slow enough today. bcrypt lets you adapt without changing the algorithm itself.

What's Actually in Your Database

So far, we've talked about salting and cost factors as separate concepts. Here's the satisfying part: in bcrypt, they're all stored together in a single string. That string sitting in your database contains everything needed to verify a password, and once you know how to read it, it's not mysterious at all.

Here's a typical bcrypt hash:

\(2a\)12$yMMbLgN9uY6J3LhorfU9iuLAUwKxyy8w42ubeL4MWy7Fh8B.CH/yO

Let's break it down:

• $2a — the algorithm version. This tells your auth library which version of bcrypt was used to generate the hash.

• $12 — the cost factor. This is the number we talked about in the previous section. A cost factor of 12 means the hashing operation was run 2¹² times.

• \(yMMbLgN9uY6J3LhorfU9iu — the salt. The first 22 characters after the final \) are the salt, stored right there in plain text alongside the hash. Your auth library reads this back out when verifying a login.

• LAUwKxyy8w42ubeL4MWy7Fh8B.CH/yO — the hash itself. The remaining characters are the actual output of the hashing operation.

When a user logs in, your auth library doesn't need any extra information. It reads the algorithm version, cost factor, and salt directly from the stored string, hashes the login attempt using those same parameters, and compares the result. If they match, the password is correct.

This is why bcrypt verification works even though the salt is never stored separately. It was never separate to begin with.

Wrapping Up

Next time you see a bcrypt string in your database, you'll know exactly what you're looking at. The algorithm version, the cost factor, the salt, and the hash, all encoded in a single string that your auth library knows how to read.

But the bigger takeaway is this: the libraries we rely on every day aren't magic. They're carefully designed systems built on top of concepts that are worth understanding.

Knowing why bcrypt is slow, why salting works even when the salt is visible, and why fast hash functions like SHA-256 are the wrong tool for passwords makes you a more intentional developer. You'll make better decisions about cost factors, you'll recognise a poorly implemented auth system when you see one, and you'll understand why a data breach where passwords were hashed with MD5 is so much worse than one where bcrypt was used.

Behind that seamless rerouting is a graph – not a chart, but a structure of nodes (places) and edges (roads) that allows Google Maps to calculate the shortest, fastest, or least congested path from point A to point B.

Once you start noticing them, you’ll realize graphs are everywhere. If you’ve ever used:

• Google Maps to get from one city to another,

• LinkedIn to see how you’re connected to someone,

• or Git to visualize branches and merges…

…you’ve interacted with a graph.

Graphs are everywhere, in how we plan routes, recommend friends, manage project dependencies, and even predict the possible moves of a knight on a chessboard. But to use them well, we first need to understand how they’re structured and why they’re so useful.

In this article, you’ll learn:

• What a graph is and how it’s used in real-world systems

• The different types of graphs and how they’re represented in code

• How to traverse graphs using search algorithms

• And finally, how a knight’s movement in chess can be modeled using graphs, and solved using traversal techniques

Let’s start by breaking down what graphs are made of and why they show up in so many things you already use.

Table of Contents

• What is a Graph?

• Types of Graphs

• How Graphs Are Represented

• Graph Traversal

• Knight's Travails: A Real-World Graph Problem

• Wrapping Up

Prerequisites

This article is beginner-friendly, and no prior knowledge of graphs is required. To follow along with the code examples, it helps to have:

• Some familiarity with data structures like stacks and queues.

• I use Python for the code snippets, but if you’ve worked with another language, you should be able to follow along easily.

What is a Graph?

At its core, a graph is a collection of nodes (also called vertices) and edges – connections that link those nodes together.

If it sounds simple, that’s because it is. The power of graphs isn’t in their complexity, it’s in their flexibility. You can use them to represent almost anything: people, cities, web pages, tasks, game moves, and the relationships between them.

Let’s break it down:

Nodes (Vertices)

Each node is a point in the graph. It might represent:

• A location (like a city on a map)

• A person (in a social network)

• A page (for example, on the web)

• A square (like one on a chessboard)

Edges

An edge is a connection between two nodes. It could represent:

• A road between two cities

• A friendship between two users

• A hyperlink between two web pages

• A legal knight move between two squares

Edges can have direction (one-way or two-way), weight (like distance or cost), or be simple and unweighted.

Graph Visualizer

Here’s a simple graph:

In this image:

• The circles represent nodes (also called vertices)

• The lines connecting them are edges, which show that two nodes are related or connected in some way

Each node is connected to one or more other nodes, forming a network of relationships.

Types of Graphs

Now that we’ve seen what a graph looks like, let’s talk about the different ways graphs can behave.

Graphs can vary in direction, weight, and structure. Understanding these types helps us choose the right graph model for the problem we’re trying to solve.

Directed Graphs

In a directed graph (also known as a digraph), connections between nodes move in a specific direction. Think of it like a one-way street – if you can drive from Point A to Point B, that doesn't necessarily mean you can drive back the same way.

A good example of this is X (Twitter). If you follow someone on X, it doesn’t automatically mean they follow you back. Your “follow” is a one-way connection, a directed edge from you to them.

This kind of graph is especially useful in situations where relationships are not mutual. On the internet, links between web pages behave the same way. Page A might link to Page B, but Page B might not link back. Similarly, in workflow systems or task pipelines, each step flows into the next in a specific order, and you generally don’t loop back – Step 1 leads to Step 2, and so on.

Undirected Graphs

An undirected graph represents relationships that go both ways. If there’s a connection between node A and node B, you can travel in either direction.

A common example is a friendship on Facebook. If you’re friends with someone, the connection is mutual by default. It wouldn’t make sense to be “half-friends”.

Undirected graphs are useful when the relationship itself is mutual and symmetrical, like shared devices on a network or road systems where travel is allowed both ways.

The key difference here is that edges are just lines, not arrows – they don’t imply flow or hierarchy, just connection.

Weighted Graphs

A weighted graph is one where each connection (edge) carries extra information, usually a number representing distance, cost, time, or importance.

Consider how you use Google Maps to get from one location to another. The app doesn’t just look for any route, it looks for the one that takes the least time, travels the shortest distance, or uses the least fuel. All of those are weights.

In a graph like this, two cities might be connected, but one road might take 5 minutes while another takes 20, so the edge between those cities isn’t just a line – it’s a line with a value.

This structure lets us make smarter decisions. We can ask questions like:

• What’s the cheapest way to reach a destination?

• Which route avoids the most traffic?

• What’s the fastest route from node A to node Z?

If undirected and directed graphs describe who is connected to whom, weighted graphs help us understand how strong, far, or costly those connections are.

Unweighted Graphs

In an unweighted graph, all edges are treated equally. A connection either exists, or it doesn’t – there’s no extra value or cost attached.

Think of a group of friends where you only care about whether two people know each other. You’re not trying to measure how close they are or how often they talk, you just want to map the presence or absence of a relationship.

Unweighted graphs are useful for modeling systems where the existence of a connection is more important than any nuance of how strong it is. These are great for representing basic relationships, board game states, or decision trees where each path is considered equally likely or valuable.

In short, unweighted graphs are all about the “yes/no,” not the “how much.”

Cyclic Graphs

A cyclic graph is one where it’s possible to loop back to where you started. You can travel through a series of connections and eventually end up at the same node.

If you’ve ever looked at a city map or used a public transit system with circular routes, you’ve seen a cycle in action. You might start at a station, ride the train through several stops, and eventually return to where you began, without ever retracing your exact steps.

Cyclic graphs are especially useful in simulations, games, or real-world systems where loops are part of the design, like control circuits or repeated workflows. They’re a natural fit for any scenario where repetition or return paths matter.

But they can also introduce complexity, especially in algorithms that aren’t meant to handle cycles. Recognizing whether your graph has cycles is often an important first step in choosing the right traversal method.

Acyclic Graphs

An acyclic graph is the opposite of a cyclic one – there are no loops. Once you start moving through the graph, you can’t return to a node you’ve already visited by following the direction of the edges. They can either be directed or undirected graphs.

Think of task management systems where some tasks depend on others. You can't complete Task C until you’ve finished Task B, and you can't start B until A is done. There’s a natural order, and no looping back.

Acyclic graphs are common in:

• Scheduling systems

• Organizational charts

• Tutorial progression systems (like one chapter unlocking the next)

Directed Acyclic Graphs

A Directed Acyclic Graph or DAG is a type of acyclic graph where every edge has a direction, and you can’t form any cycles. It’s like a roadmap where all roads point forward and never loop.

This structure is incredibly common in computing, especially when you need to track progress, dependencies, or history.

In Git, for example, every commit points to one or more parent commits, forming a directed graph of changes. But since commits can’t “revisit” an earlier state, the structure remains acyclic.

In package managers, a library might depend on others, but you can't have a loop. Say library A depends on B, which depends on C, which depends on A again – that would break everything. A DAG ensures that dependencies move forward, not in circles.

How Graphs Are Represented

So far, we’ve explored graphs as concepts and visuals with various types and behaviors. But when it’s time to work with graphs in code, we need a way to represent those connections in a structured format.

There are two common ways to represent a graph:

• Adjacency List

• Adjacency Matrix

Each has its strengths, and which one you use depends on the type of graph and what operations you need to perform.

Adjacency List

An adjacency list stores a graph as a collection of nodes, where each node maps to a list of its neighbors (nodes it’s connected to). An adjacency list is one of the most intuitive ways to represent a graph. But how you write this list depends on the type of graph you’re working with.

For an undirected graph, the connection goes both ways, so each edge is written twice – once for each node.

For a directed graph, each connection only flows one way, so you only write it once, in the direction it points.

Benefits:

• Memory-efficient for sparse graphs (that is, not all nodes are connected)

• Easy to add or remove nodes and edges

• Fast to get a node’s neighbors – just read its list

Downsides:

• Slower edge lookup: To check if two nodes are connected, you have to scan a list

• Can be inefficient for dense graphs where most nodes connect to many others

• Sorting neighbors or accessing them by index is less convenient

Adjacency Matrix

An adjacency matrix uses a 2D array (or grid) to represent connections between nodes. Each row and column corresponds to a node, and the cell at the intersection tells you whether there’s a connection.

• A value of 1 means there is an edge between the two nodes.

• A value of 0 means an edge doesn’t exist between two nodes.

For an undirected graph, an edge between i and j means the connection works both ways. So if (i, j) is 1, (j, i) is also 1. This makes the matrix symmetric, that is, (i, j) == (j, i).

For a directed graph, an edge from node i to node j is at position (i, j). But this doesn’t imply that there's an edge from j to i. So in general, (i, j) ≠ (j, i).

Benefits:

• Instant edge lookup between any two nodes in O(1) time.

• Simple to implement and often used in low-node-count, dense graphs.

Downsides:

• High space complexity – even if the graph has few edges, the matrix still takes up O(V²) space.

• Inefficient for sparse graphs, where many cells are unused.

• Finding neighbors requires scanning an entire row, which takes O(V) time.

Graph Traversal

Once you’ve built a graph using adjacency lists or matrices, the next question is: how do you explore it?

Graph traversal is the process of visiting each node (and its neighbors) in a graph in a specific order. It’s a foundational technique in computer science, used in everything from web crawling to friend suggestions on social media.

Traversal is used when:

• You want to search for a specific value or node.

• You want to visit all nodes, for example, to analyze connectivity.

• You want to solve puzzles, like mazes or routing problems.

There are two primary ways to traverse a graph: Depth-First Search (DFS) and Breadth-First Search (BFS). Let’s traverse through this graph using both methods:

Breadth-First Search (BFS)

BFS starts from a node and explores all of its immediate neighbors before moving on to the neighbors of those neighbors.

It’s commonly used in:

• Finding the shortest path (in unweighted graphs)

• Level-order traversal

• Network broadcast simulations

from collections import deque

def bfs(graph, start):
    visited = set()
    queue = deque([start])

    while queue:
        node = queue.popleft()
        # node has not been visited
        if node not in visited:
            print(node)  # Visit the node
            visited.add(node)
            for neighbor in graph[node]:  # Look at each neighbor of the current node
                if neighbor not in visited:     
                    queue.append(neighbor)  

# Undirected graph
graph = {
    'A': ['B', 'C'],
    'B': ['A', 'D'],
    'C': ['A', 'D'],
    'D': ['B', 'E'],
    'E': ['D']
}

bfs(graph, 'A')

Here’s the output of the code above:

A
B
C
D
E

What This Code Does:

Step 1: Choose a Starting Point
Pick the node where you want to begin the traversal. Add it to a queue.

Step 2: Visit the Node at the Front of the Queue
Take the first node from the queue (this is your current node) and mark it as visited. Do something with it, like printing its value.

Step 3: Add Its Neighbors to the Queue
Look at all the nodes directly connected to the current node (its neighbors). For each neighbor, if it hasn't been visited yet, add it to the end of the queue.

Step 4: Repeat Until the Queue Is Empty
Go back to Step 2. Keep visiting the node at the front of the queue and enqueue its unvisited neighbors until no more nodes are left in the queue.

Depth-First Search (DFS)

DFS dives deep into one path of the graph before backtracking and exploring other branches.

It’s useful for:

• Cycle detection

• Topological sorting

• Solving puzzles like mazes (where the shortest path doesn’t matter)

def dfs(graph, start):
    visited = set()
    stack = [start]

    while stack:
        node = stack.pop()
        if node not in visited:
            print(node)  # Visit the node
            visited.add(node)
            for neighbor in graph[node]:
                if neighbor not in visited:
                    stack.append(neighbor)


# Example graph (same as before)
graph = {
    'A': ['B', 'C'],
    'B': ['A', 'D'],
    'C': ['A', 'D'],
    'D': ['B', 'E'],
    'E': ['D']
}

dfs(graph, 'A')

Here’s the output of the code above:

A
C
D
E
B

Just like BFS, we:

• Track visited nodes with a set

• Use a loop to process each node

• Visit neighbors one by one

But here’s the important difference: DFS uses a stack, so it goes deep into one path until it can’t go further, then it backtracks and explores the next path. This makes it great for tasks like solving mazes or exploring all possibilities in a decision tree.

Wrapping Up Graph Traversal

Understanding how to traverse a graph is foundational to solving many real-world problems, from mapping routes to analyzing social networks. Whether you're using BFS to find the shortest path or DFS to explore deep relationships, choosing the right traversal method depends on the problem you're trying to solve.

Knight's Travails: A Real-World Graph Problem

To bring graphs to life, let’s start with a simple example.

Imagine you're playing chess, and your knight is stuck in one corner of the board. Let’s say you want to move it to a specific square to defend your queen. What’s the fewest number of moves it’ll take to get there?

This is a classic graph problem.

Each square on the chessboard can be represented as a node. If a knight can legally move from one square to another, there's an edge between them. The knight’s movement rules – those L-shaped hops – define the graph’s edges. So if you think about it, you're navigating a graph, trying to find the shortest path from one node (start square) to another (target square).

Let’s break it down.

Modeling the Board as a Graph

• The chessboard is an 8x8 grid.

• Each square is a node, identified by its coordinates (x, y) where 0 ≤ x < 8 and 0 ≤ y < 8.

• A knight has a maximum of 8 possible moves from any position (some may be out of bounds).

• The goal is to build a graph where each node connects to all valid knight moves from that square.

BFS or DFS? Choosing the Right Tool

There are two traversal methods we discussed earlier, Breadth-First Search (BFS) and Depth-First Search (DFS). So, which one should we use to solve the Knight’s Travails problem?

Let’s think about what would happen if we used DFS.

DFS goes as deep as it can along one path before backtracking. So, if you use DFS to move the knight, it might follow a long, winding sequence of valid moves that eventually leads to the destination, say, in 7 moves.

But that doesn’t mean it’s the shortest path. The optimal path could have reached the target in just 3 or 4 moves, but DFS wouldn’t find that unless it happens to explore that exact path first.

Even worse, DFS doesn’t guarantee you’ll find the shortest path unless you exhaustively search every possibility and compare them, which is slow and inefficient for this kind of problem.

Now, here’s why BFS is a better fit.

BFS explores all positions the knight can reach in 1 move, then all positions reachable in 2 moves, then 3 moves, and so on. As soon as it finds the destination square, you can be sure it got there using the fewest possible steps, because it explores all shorter paths before any longer ones.

In short:

• DFS might reach the destination eventually, but not efficiently, and not necessarily via the shortest path.

• BFS guarantees that the path it returns is the shortest in terms of the number of moves.

That’s why, for problems like this, where minimum steps are the goal, BFS is the go-to approach.

Implementing Knight’s Travails with BFS

To model the knight’s traversal across the board, we’ll use a class called Square. This class will help us track:

• The knight’s current position on the board (x_coord, y_coord)

• A reference to its parent square, so we can reconstruct the shortest path once the destination is reached

• Keep track of all valid next moves (its children), which represent the squares the knight can legally move to from the current position

Here’s the initial class:

from collections import deque

# Class to represent a square on the chessboard
class Square:
    def __init__(self, x_coord, y_coord, parent=None):
        self.x_coord = x_coord
        self.y_coord = y_coord
        self.parent = parent
        self.children = []

This setup is useful because we’re building a path tree: each move creates a child node, and we can trace our way back to the starting point using the parent.

How Does a Knight Move?

A knight in chess moves in an “L” shape, two steps in one direction and one step perpendicular to it. If the knight is at the center of an 8x8 chessboard, it can make up to 8 legal moves. These moves can be visualized as edges connecting one square (node) to others.

Here’s how we can represent and generate those moves:

from collections import deque

# Class to represent a square on the chessboard
class Square:
    def __init__(self, x_coord, y_coord, parent=None):
        self.x_coord = x_coord
        self.y_coord = y_coord
        self.parent = parent
        self.children = []

    def generate_legal_moves(self):
        # All 8 possible knight moves (in L-shape)
        row_moves = [-2, -1, 1, 2, 2, 1, -1, -2]
        col_moves = [1, 2, 2, 1, -1, -2, -2, -1]

        for dx, dy in zip(row_moves, col_moves):
            nx, ny = self.x_coord + dx, self.y_coord + dy

            # Only add valid board positions (0–7 for an 8x8 board)
            if 0 <= nx < 8 and 0 <= ny < 8:
                self.children.append(Square(nx, ny, self))

Finding the Shortest Path

Now that we have the Square class and the knight’s possible moves, we should implement BFS to find the shortest path from a starting square to a destination.

# BFS function to find the shortest path from start to end square
def knight_travails(start_coords, end_coords):
    # Initialize the BFS queue with the starting square
    start_x, start_y = start_coords
    queue = deque([Square(start_x, start_y)])
    # Set to track visited positions and prevent revisiting
    visited = set()
    end_coords = tuple(end_coords)

    while queue:
        current = queue.popleft()
        coords = (current.x_coord, current.y_coord)

        # If this square is the target, we've found the shortest path
        if coords == end_coords:
            return current

        # Skip, if this position has already been visited
        if coords in visited:
            continue

        visited.add(coords)

        # Generate all legal knight moves from the current square
        current.generate_legal_moves()
        # Append children to queue
        queue.extend(current.children)

def construct_path(start, end):
    # Run BFS to get the final square
    end_square = knight_travails(start, end)
    path = []

    # Trace back from the end square to the start using the parent links
    while end_square:
        path.append((end_square.x_coord, end_square.y_coord))
        end_square = end_square.parent

    # Reverse the path to show it from start to end
    return path[::-1]

Once you’ve implemented the functions above, you can print the output like this:

print(construct_path([3, 4], [0, 1]))

This returns the shortest sequence of moves the knight must take to travel from [3, 4] to [0, 1]. Sample output:

[(3, 4), (2, 2), (0, 1)]

Each tuple represents a square on the chessboard that the knight visits. This is the shortest possible path the knight can take (from start to end square) – and thanks to how BFS works, we know for sure that no shorter path exists. That guarantee of optimality is what makes Breadth-First Search a perfect fit here.

Wrapping Up

From chessboards to road maps and airline routes, graphs are everywhere. They silently power much of the technology we rely on daily. Whether you're booking a flight, navigating a city, or getting a recommendation on your favorite app, graphs are often at work behind the scenes.

They allow you to model and solve complex real-world problems by connecting entities and exploring their relationships. So next time your Google Maps reroutes you, remember: graphs are the mechanism behind that magic. Once you start recognizing graphs, you start seeing the hidden structure behind apps, systems, and even games you use every day.

But behind those helpful messages is a powerful system of rules and structure that most of us rarely explore.

Linters are everywhere – across languages, frameworks, and workflows. They help catch errors, enforce consistent formatting, and promote best practices. They’re among the first tools we install in a new project, and yet they’re also some of the most underrated and least understood.

In this article, I’m going to take you under the hood. We’ll look at how JavaScript lint rules work, why ASTs (Abstract Syntax Trees) are such a big deal, and how you can use this understanding to write or contribute to a linter yourself.

📚 Table of Contents

• What Even Is a Linter?

• From Code to Tree: Enter the AST

• Why ASTs Matter for Linting

• How ESLint Uses ASTs Under the Hood

• Anatomy of a Lint Rule

• Helpful Tools for Exploring ASTs

• Wrapping Up: Why You Should Understand This

🧹What Even Is a Linter?

A linter is a tool that automatically analyzes your code to flag errors, enforce style rules, and catch potential bugs. Think of it as the Grammarly of the coding world – helping you write cleaner, more consistent code by pointing out problems early.

A popular example is ESLint, an open-source linter for JavaScript and TypeScript that checks code for issues and can even auto-fix some of them.

Linters are often:

• Integrated into your text editor or IDE

• Run as part of a CI pipeline or pre-commit hook

• Used alongside formatters like Prettier for even stricter consistency

But how do they decide what to flag as an issue? That’s where lint rules come in.

🧱 Lint Rules: The Brains Behind the Linter

Lint rules are the building blocks of any linter. Each rule defines:

1. What to look for: a specific pattern in your code.

2. What to do about it: a warning, an error, or an auto-fix.

There are many types of rules, often grouped into categories like:

• Error prevention: Catching bugs, like using undeclared variables.

• Code style: Enforcing consistent formatting and naming conventions.

• Best practices: Encouraging safer or more readable coding patterns.

• Security: Flagging risky code, like direct eval() calls or unsafe regex.

If you’ve ever seen an ESLint message like this:

Unexpected console.log

Missing semicolon

'myVar' is assigned a value but never used

…you’ve seen lint rules in action.

They’re not just “style police.” Linters help reduce mental overhead by catching little issues early, so you can focus on the bigger picture of what your code is trying to do.

🌳 From Code to Tree: Enter the AST

To understand how lint rules work under the hood, we need to talk about the Abstract Syntax Tree (AST) – the data structure at the heart of every linter.

An AST is a structured, tree-like representation of your code. Instead of reading your code as raw text, a linter converts it into a tree where each part of your code (a variable, a string, a function, and so on) becomes a node in the tree.

Here’s an example.

Paste this code into AST Explorer, a tool that lets you view the AST for code in real time:

const name = "Tilda";

Set the language to JavaScript, and choose one of the ESLint parsers like Espree. You’ll see something like this in the right panel:

In the image above from AST Explorer, you can see how the tree is structured:

• Program:

  • The root node of the AST. It wraps the entire code.

  • Contains a body, which is an array of statements.

• VariableDeclaration

  • Type: "VariableDeclaration"

  • Represents a declaration using the const keyword.

  • Has a kind of "const" and a list of declarations.

• VariableDeclarator

  • Type: "VariableDeclarator"

  • Represents a single variable being declared.

  • Contains two key parts:

    • Identifier

      • Type: "Identifier"

      • Name: "name"

      • This is the variable being declared.

    • Literal

      • Type: "Literal"

      • Value: "Tilda"

      • This is the string being assigned to the variable.

This nesting is what makes the structure “tree-like”. Each node is a parent to smaller pieces (its children), which helps linters navigate code reliably.

So while your eyes see a short line of JavaScript, the linter sees a detailed map of what that line means structurally. This hierarchy allows tools like ESLint to pinpoint exactly what kind of code is being used – and where – so rules can target patterns like:

• "Flag all const variables"

• "Warn when a variable is named name"

• "Disallow hardcoded strings like Tilda"

🤖 Why ASTs Matter for Linting

Now, here’s the key idea: lint rules don’t work by reading your code like text. They work by matching specific node patterns in the AST.

That matters a lot because there are dozens of ways to write the same logic in JavaScript. Let’s take two versions of the same logic: one written as a function declaration, and one as an arrow function.

function greet() {
  return "hello";
}

const greet = () => "hello";

At a glance, they look different. But when we examine their ASTs, we see that both follow similar structural patterns. This is what allows a linter to recognize what your code is doing, no matter how it’s written.

🌳 The Tree Behind the Function Declaration

Here’s what ESLint sees in the AST tree when you write a function declaration:

• It starts with a FunctionDeclaration node.

• That node contains:

  • An Identifier (the function name: greet)

  • A BlockStatement representing the function body

  • Inside the BlockStatement, there’s a ReturnStatement

  • The ReturnStatement returns a Literal — the string "hello"

🌳 The Tree Behind the Arrow Function

Here’s what ESLint sees when you write the same logic using an arrow function:

• A VariableDeclaration with kind: "const"

  • Inside it, a VariableDeclarator, which assigns a value to the greet variable

  • The value is an ArrowFunctionExpression

  • The body of the arrow function is a Literal — the string "hello"

Even though the syntax is different, both paths eventually lead to a Literal node containing "hello" – which is all your linter needs to care about.

💡 Let’s Bring It Home with an Example

Imagine your team has a rule: functions shouldn’t return hardcoded strings like "hello". You want a linter that flags this.

With ASTs, you can write one lint rule that matches a ReturnStatement or an ArrowFunctionExpression whose body is a Literal.

Here's the basic idea:

ReturnStatement(node) {
  if (node.argument?.type === "Literal" && node.argument.value === "hello") {
    context.report({ node, message: "Avoid returning static 'hello' strings." });
  }
}

And for arrow functions with expression bodies:

ArrowFunctionExpression(node) {
  if (node.body?.type === "Literal" && node.body.value === "hello") {
    context.report({ node, message: "Avoid returning static 'hello' strings." });
  }
}

Even though the code styles are different, the structure of the AST is similar enough that both functions will trigger the rule, because the linter isn’t looking at how the code is written, only what the structure of the AST actually is.

This is what makes ASTs so useful: they let linters ignore surface-level differences and focus on the actual meaning and structure of your code. As a result, you can write smarter, more flexible rules that catch patterns across different styles, no matter how someone wrote their JavaScript.

🔨 How ESLint Uses ASTs Under the Hood

ESLint relies on a standardized format called ESTree (ECMAScript Tree) to represent JavaScript code as an Abstract Syntax Tree (AST). ESTree isn’t a parser itself – it’s a specification that defines how JavaScript code should be represented as a tree. This makes it possible for ESLint (and similar tools) to understand code in a consistent, structured way.

When you run ESLint on your code, here’s what’s happening under the hood:

1. Your Code Is Parsed into an AST

ESLint converts your code into an AST that follows the ESTree format. This tree is made up of nodes, each representing a piece of your code (like a variable, function, or expression). The resulting structure is what every lint rule will analyze.

2. Lint Rules “Subscribe” to Specific Node Types

Each lint rule tells ESLint which node types it wants to listen to. For example, a rule might care about:

• Identifier

• CallExpression

• VariableDeclaration

These node types match the structure you’d see in tools like AST Explorer.

3. ESLint Traverses the Tree and Triggers Rules

ESLint walks through the AST, visiting one node at a time. When it reaches a node type that a rule has subscribed to, it triggers the corresponding function in that rule.

This process is efficient and declarative, you don’t have to worry about manually scanning through every line of code. ESLint does the walking, your rule just listens.

4. Rules Inspect Nodes and Report Problems

Inside each rule, you receive the node ESLint has passed in. You can look at its properties – like name, value, or surrounding structure – and decide whether it violates your intended pattern.

If it does, you use context.report() to tell ESLint to flag it as an issue. ESLint can also fix the issue automatically if you provide a fix() function inside context.report().

context.report({
    node: node,
    message: "Missing semicolon".
    fix: function(fixer) {
        return fixer.insertTextAfter(node, ";");
    }
});

🩻 Anatomy of a Lint Rule

Let’s look at a very simple custom ESLint rule. This one flags any variable named any:

module.exports = {
  meta: {
    type: "problem",
    docs: {
      description: "Disallow variables named 'any'",
    },
  },

  create(context) {
    return {
      Identifier(node) {
        if (node.name === 'any') {
          context.report({
            node,
            message: "Don't use 'any' as a variable name."
          });
        }
      }
    };
  }
};

🔎 What’s happening here:

• The meta section provides info about the rule (used in ESLint docs and tooling).

• The create() function defines which node types the rule listens for.

• Identifier(node) is triggered every time an identifier is found in the code.

• If the identifier’s name is any, the rule calls context.report() to raise a warning.

🛠 Helpful Tools for Exploring ASTs

Understanding ASTs can feel abstract at first, but some tools make the learning curve much smoother. These are especially helpful when you’re trying to visualize how your code translates into tree structures, or when debugging a custom rule.

1. AST Explorer

This is the most beginner-friendly and powerful tool for working with ASTs. You can:

• Paste in any JavaScript code

• Choose an ESLint-compatible parser (like Espree)

• Instantly see the AST structure on the right-hand side

• Hover over tree nodes and see how they map to specific parts of your code

If you're writing a custom rule, AST Explorer will likely become your best friend. It helps you figure out exactly which node type you need to target and what properties are available on that node.

2. ESLint’s Rule Examples and Tests

Sometimes the best way to learn is to read real code. ESLint's core rules (or rules from popular plugins like eslint-plugin-react) include:

• Rule definitions

• Test files showing code that should and shouldn’t trigger the rule

• Fix examples (if the rule is auto-fixable)

Browsing these helps you understand how real-world rules are structured and how the test setup works.

Tip: Look in the tests/lib/rules/ or lib/rules/ folders of ESLint or plugin repositories.

3. ESLint’s Documentation

ESLint has comprehensive documentation about working with rules:

• ESLint: Working with Rules

• ESLint: Custom Rules

✅ Wrapping Up: Why You Should Understand This

Understanding how ASTs work gives you superpowers when it comes to customizing and contributing to linting tools. Whether you're trying to enforce a specific pattern in your team’s codebase or want to contribute to a plugin like eslint-plugin-react, this knowledge will help you:

• 🔧 Contribute to existing rules by understanding what they’re checking and how

• 🐛 Debug confusing linter behavior when rules fire unexpectedly (or not at all)

• 🛠 Write your own custom rules to enforce specific coding standards, project conventions, or best practices

You don’t need to be a compiler expert or fully grasp every node type in the spec. You just need to recognize patterns, explore trees, and get comfortable identifying the nodes your rule cares about.