# How to Use Regular Expressions in JavaScript: The clean-code-javascript Guide

> Learn how to use regular expressions in JavaScript with the clean-code-javascript guide. Discover tips for named constants and descriptive variables to enhance readability and eliminate mental mapping.

- Repository: [Ryan McDermott/clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript)
- Tags: deep-dive
- Published: 2026-02-27

---

**The clean-code-javascript guide recommends treating regular expressions as named constants with descriptive variable assignments for capture groups to eliminate "mental mapping" and improve code readability.**

The ryanmcdermott/clean-code-javascript repository is a widely-adopted style guide that translates Robert C. Martin's "Clean Code" principles into JavaScript. When it comes to regular expressions, the guide treats them as "magic" patterns that can severely harm readability if used inline without proper naming conventions.

## Name Your Regular Expressions to Avoid Mental Mapping

The guide emphasizes that unnamed regular expressions force developers to perform **mental mapping**—simultaneously decoding complex pattern syntax while trying to understand business logic. According to the documentation in [`README.md`](https://github.com/ryanmcdermott/clean-code-javascript/blob/main/README.md) (lines 116-119), you should assign regular expressions to clearly-named constants that describe their purpose.

Instead of scattering raw patterns throughout your code, isolate them with descriptive identifiers like `cityZipCodeRegex` or `emailValidationRegex`. This makes the intent immediately visible without requiring readers to parse the pattern itself.

## Destructure Capture Groups into Explanatory Variables

Once you've performed a match, the guide strongly advises against accessing capture groups through obscure numeric indices like `[1]` or `[2]`. As documented in [`README.md`](https://github.com/ryanmcdermott/clean-code-javascript/blob/main/README.md) (lines 127-128), you should immediately destructure the match result into well-named variables that explain what each capture group represents.

This practice transforms cryptic array access into self-documenting code. Rather than forcing future maintainers to mentally map indices to regex groups, variable names like `city` and `zipCode` make the data's purpose explicit.

## Bad vs. Good: A Practical Comparison

The repository provides concrete examples demonstrating the difference between these approaches.

**Bad: Inline regex with obscure indexing**

```javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
saveCityZipCode(
  address.match(cityZipCodeRegex)[1], // unclear what [1] is
  address.match(cityZipCodeRegex)[2]  // unclear what [2] is
);

```

**Good: Named regex with explanatory variables**

```javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;

// Destructure the match result into clearly-named variables
const [_, city, zipCode] = address.match(cityZipCodeRegex) || [];

saveCityZipCode(city, zipCode);

```

## Summary

- Treat regular expressions as first-class citizens by assigning them to descriptively named constants
- Avoid forcing readers to decode complex pattern syntax while simultaneously understanding business logic
- Always destructure capture groups into well-named variables instead of using numeric indices like `[1]` or `[2]`
- Keep regex patterns isolated from business logic to maintain long-term readability

## Frequently Asked Questions

### Why does clean-code-javascript recommend naming regular expressions?

The guide treats unnamed regex patterns as "magic" that forces developers to perform mental mapping—decoding complex syntax while simultaneously understanding business logic. Naming them (e.g., `cityZipCodeRegex`) makes the pattern's intent immediately visible without requiring readers to parse the regular expression itself.

### What is wrong with using array indices like [1] and [2] on regex matches?

Numeric indices create hidden dependencies that require readers to mentally parse the regex pattern to understand what each group represents. The guide recommends destructuring into named variables (e.g., `const [_, city, zipCode] = ...`) for self-documenting code that eliminates the need to cross-reference the pattern definition.

### Where in the clean-code-javascript repository are these regex recommendations documented?

These guidelines appear in the [`README.md`](https://github.com/ryanmcdermott/clean-code-javascript/blob/main/README.md) file at lines 116-119 (naming conventions to avoid mental mapping) and lines 127-128 (destructuring capture groups into explanatory variables), within the section discussing how to handle regular expressions cleanly.

### Should I always extract regular expressions into constants even if used only once?

According to the guide, yes—if the regex performs meaningful validation or extraction that requires mental effort to understand. Isolating it with a descriptive name improves readability even for single-use patterns, though simple literal matches that are immediately obvious (like `/\s+/` for whitespace) might not require this treatment.