Read 50 Lines of Code or Use Extract Method Refactoring? - Insights from Derek Comartin

The Example: User Sign-Up in a Chat System

At the beginning of the video, Derek presents an example: a sign-up feature for a chat system. It’s a compact but realistic code block of about 50 lines that performs several tasks:

• Checks if the username is not blank

• Verifies if the username is already taken

• Handles age-restricted channels

• Saves the new user object

• Sends an email with an activation link

This code resides in one function, and at first glance, it might look like a great candidate for extract method refactoring. But as Derek warns, blindly refactoring without understanding the impact can actually degrade clarity.

Starting With Refactoring: Select Extract Method

Derek starts where many developers do—by breaking the code fragment into smaller pieces. He shows how to select Extract Method either through the context menu or a keyboard shortcut in most IDEs or code editors.

He extracts:

• validateUsername to verify the username isn’t blank

• existingSignUpNotActivated to check for an unactivated account

• validateExistingUser to handle all existing user checks

• filterAgeRestrictedChannels to process channels for users under 18

• sendEmail to issue the welcome email

He gives each new function a meaningful name, which is one of the top tips often promoted in clean code practices. But as he walks through these modified versions, Derek begins to point out the cracks in the logic—not in the functionality, but in readability and control flow.

Issue 1: Hidden Implementation Details

One of the first red flags Derek highlights is that implementation details are now hidden behind extracted methods.

For example, the validateUsername and validateExistingUser methods actually throw exceptions. But as a developer reading the refactored code, you’d have no idea unless you access their internals.

This kind of refactoring can hide control logic, leading to bugs or missed validations. The scope and flow are no longer obvious. Instead of making the code clearer, you’re creating a maze of abstractions where side effects like exceptions or modified variables are no longer visible at the form where the logic was originally written.

Issue 2: Indirection and Chained Extracts

Next, Derek points out the issue of indirection—when one extract method calls another, and so on. He shows how the validateExistingUser method is itself composed of existingSignUpNotActivated.

You’re no longer reading a straightforward top-down code block. You’re hopping between methods, files, and classes just to trace what happens. And while the editor may help navigate this flow, it becomes a burden on the reader’s cognitive load.

This becomes even more painful in larger systems where refactoring spans across multiple files or components. Suddenly, your “clean code” appears harder to follow than the original “messy” 50 lines.

Issue 3: Local Variables and Mutating State

One of the most important lessons in this video comes from the handling of local variables and state mutation.

Derek spotlights the filterAgeRestrictedChannels method. It doesn’t return a result—it directly mutates the channels list that was passed in. This means you're modifying local state from within a different method, and unless you inspect the method closely, this change is hidden.

This breaks the expectation that a function is either a pure operation or clearly signals when it's changing things. When you replace logic with a new method that doesn’t return values but changes them internally, you're introducing risk and confusion.

Derek’s Refactored Alternative

So how does Derek actually refactor his old code?

He proposes a much simpler approach:

1. Keep self-explanatory logic inline. The initial check for an empty username remains in the main method, as it’s easy to understand and doesn't clutter the codebase.

2. Return results instead of mutating. Instead of mutating the channels list, the filterAgeAppropriateChannels function now returns a filtered list. This makes the data flow clear and prevents unexpected side effects.

3. Use simple, predictable extract methods. The only other extracted method is isExistingUserAlreadyActivated, which clearly returns a boolean without throwing exceptions. It encapsulates logic without hiding details.

4. Avoid inline side effects like email sending. Derek leaves the email logic in place for demonstration, but suggests that in a real system, this should be handled via an event in a separate process or thread—not something tied directly to the user form submission.

In total, Derek only uses two extract methods and leaves the rest of the logic inline—because it is easier to read, reason about, and control.

Final Tips on Extract Method Refactoring

Derek’s video leaves us with some practical guidelines for using extract method refactoring effectively:

• Use meaningful names that describe exactly what the method does.

• Avoid side effects like state mutation or exception throwing unless they’re obvious.

• Return values instead of modifying input parameters.

• Don’t hide logic behind multiple layers of abstraction.

• If a method appears readable in its original form, don’t force it into multiple functions just for the sake of refactoring.

Sometimes, the best abstraction is no abstraction—especially when it comes at the cost of clarity and scope awareness.

Conclusion

Derek Comartin’s approach challenges the notion that refactoring always improves code. In the case of extract method refactoring, less is often more. Instead of over-using select Extract Method to chop up your logic, evaluate what adds value, what makes your code easier to understand, and what hides important details.

With clear examples and direct insight into real-world code, Derek in his video shows that sometimes 50 lines in a single method, read top-down like a story, are better than ten smaller methods spread across your codebase.

If you’ve ever reached for that keyboard shortcut to create a new method, remember Derek’s advice: pause, evaluate, and make sure the refactoring serves the reader—not just the IDE.