DEV Community

Timevolt
Timevolt

Posted on

How I Learned to Stop Worrying and Love Small Functions: A Code Review Quest Inspired by *The Matrix*

#cleancode #softwaredevelopment #programming #bestpractices

The Quest Begins (The "Why")

I still remember my first big code review like it was yesterday. I’d just finished a feature that let users upload avatars, resize them, and store the thumbnails in S3. Proud of my work, I tossed the pull request over the wall and waited for the thumbs‑up. Instead, I got a wall of comments: “This function does too much,” “Where’s the error handling?” “Why is this 200 lines long?” I felt like Neo staring at the code‑rain, trying to see the pattern but only seeing chaos.

The problem wasn’t that my logic was wrong—it was that I’d bundled everything into one monolithic function: validation, image processing, uploading, logging, and even a little bit of UI feedback. When a bug popped up in production (a user’s avatar turned into a garbled pink mess), I spent three hours tracing through that beast, only to discover the issue was a missing null check buried halfway down. The review had highlighted the symptom, but the real dragon was the function’s size and lack of clear intent.

That experience sparked a question: What if I could write code that reviewers could skim in seconds, not minutes? The answer turned out to be simpler than I expected, and it changed the way I approach every line I type.

The Revelation (The Insight)

The best practice that transformed my code—and my sanity—was writing small, single‑responsibility, pure functions. In plain English: each function should do one thing, have no side effects unless absolutely necessary, and be easy to test in isolation. When you follow this rule, your code reads like a series of short, clear sentences instead of a dense novel.

Why does this matter? Because code reviews become a conversation about intent rather than a scavenger hunt for hidden logic. Reviewers can spot missing edge cases quickly, and you gain confidence to refactor without fear of breaking something else. Plus, when a bug does surface, the offending unit is tiny—often just a handful of lines—making debugging feel like solving a puzzle instead of defusing a bomb.

Wielding the Power (Code & Examples)

Let’s look at a concrete before/after. Imagine we need to validate a user’s bio, sanitize it, count words, and store it in a database.

Before: The “Do‑It‑do‑everything‑and‑then‑some” Function 

function processUserBio(rawBio) {
  // 1️⃣ Validate length
  if (!rawBio || rawBio.length > 500) {
    throw new Error('Bio too long or missing');
  }

  // 2️⃣ Sanitize HTML (very naive)
  let clean = rawBio.replace(/<[^>]*>/g, '');

  // 3️⃣ Count words
  const wordCount = clean.trim().split(/\s+/).filter(Boolean).length;

  // 4️⃣ Log for audit
  console.info(`[${new Date().toISOString()}] Bio processed, words: ${wordCount}`);

  // 5️⃣ Persist to DB (pseudo‑code)
  db.saveUserBio({ bio: clean, wordCount });

  // 6️⃣ Return a summary for the caller
  return { bio: clean, wordCount };
}
Enter fullscreen mode Exit fullscreen mode

What’s wrong here?

  • It mixes validation, sanitization, metrics, logging, persistence, and return‑value construction.
  • A reviewer must hold all those steps in mind to see if any are missing or flawed.
  • Testing this function means mocking the console, the DB, and checking side effects—painful and brittle.
  • If the word‑count algorithm changes, you risk breaking the logging or DB call unintentionally.

After: Small, Pure Functions with Clear Names 

// 1️⃣ Validation – pure, throws on bad input
function validateBio(bio) {
  if (!bio || bio.length > 500) {
    throw new Error('Bio too long or missing');
  }
}

// 2️⃣ Sanitization – pure, returns a new string
function sanitizeBio(bio) {
  return bio.replace(/<[^>]*>/g, '');
}

// 3️⃣ Word counting – pure, no side effects
function countWords(text) {
  return text.trim().split(/\s+/).filter(Boolean).length;
}

// 4️⃣ Logging – side‑effect isolated, easy to stub/test
function logBioProcessed(wordCount) {
  console.info(`[${new Date().toISOString()}] Bio processed, words: ${wordCount}`);
}

// 5️⃣ Persistence – side‑effect isolated
function saveBioToDb(bio, wordCount) {
  return db.saveUserBio({ bio, wordCount });
}

// 6️⃣ Orchestrator – reads like a recipe
function processUserBio(rawBio) {
  validateBio(rawBio);
  const clean = sanitizeBio(rawBio);
  const wc = countWords(clean);
  logBioProcessed(wc);
  return saveBioToDb(clean, wc);
}
Enter fullscreen mode Exit fullscreen mode

Why this feels like a power‑up:

  • Each helper is tiny and pure (except the intentional side‑effects in logBioProcessed and saveBioToDb).
  • Unit tests are trivial: test validateBio with edge cases, test countWords with various strings, mock the logger and DB in the orchestrator test.
  • A reviewer can glance at processUserBio and instantly see the pipeline: validate → sanitize → count → log → save. No hidden steps.
  • If we need to change the word‑count algorithm, we only touch countWords. The logger and DB calls remain untouched, drastically reducing regression risk.

Common Traps to Avoid

  1. Over‑splitting for the sake of splitting – Don’t create a function that just returns its argument (function identity(x){return x;}) unless it adds clarity or reuse.
  2. Leaking state through globals – Keep side effects explicit; if a function needs to modify something, pass it in as a parameter or return a new value.
  3. Naming vagueness – processData() tells me nothing; normalizePhoneNumber() tells me exactly what to expect.

Why This New Power Matters

Adopting this practice turned my code reviews from dreaded interrogations into collaborative walkthroughs. My teammates started leaving comments like “Nice, the flow is obvious” instead of “What does this line do?”. When a production incident hit, I could isolate the faulty function in minutes, write a failing test, fix it, and deploy—all while feeling like I’d just cleared a boss level in a RPG (that’s the one pop‑culture nod, by the way: it felt like finding a hidden warp pipe in Super Mario when the tests finally turned green).

More than that, it changed how I write code. I now pause before adding a line and ask: Does this belong here, or should it be its own function? That tiny habit has trimmed my functions’ average length from ~80 lines to under 20, reduced bugs, and made onboarding new developers a breeze. The team’s velocity went up, and honestly, it feels like we’ve leveled up together.

Your Turn

Grab the next function you’re tempted to write that’s longer than a tweet. Break it down into two or three smaller pieces, give each a clear intention‑revealing name, and watch the review comments turn from “???” to “👍”. Give it a try and drop a link to your refactored snippet in the comments—I’d love to see your quest in action! Happy coding!

Top comments (0)