What Do Both Of These Functions Have In Common

Understanding Function Parallels in Code

When you're reading through a codebase, you'll often run into two functions that look completely different on the surface but are doing basically the same thing. I've spent years maintaining legacy systems where someone wrote a validation function in 2016 and another developer wrote a nearly identical one in 2022 without knowing. The question of what do both of these functions have in common comes up constantly in code reviews and refactoring sessions. The answer isn't always obvious. You might see one function returning a boolean and another returning an integer, or one using exceptions while the other uses error codes. But underneath, they share the same core logic structure. This is what separates junior developers from senior ones - the ability to look past syntax differences and identify the shared pattern.

What Do Both Of These Functions Have In Common

Let me walk through a concrete example from my own work. I was debugging a payment processing system where two functions handled currency conversion - one for USD to EUR and another for USD to GBP. At first glance they looked unrelated. The first used a simple multiplication factor stored in a database. The second called an external API with error handling, retries, and logging. But when I traced through the actual logic flow, both functions shared an identical three-step pattern: fetch the rate, apply the rate to the input amount, and return the formatted result. The key insight here is that function similarity is about control flow, not syntax. Two functions can use different variable names, different data sources, different error handling strategies, and still be functionally equivalent at their core. This matters because when you identify this commonality, you can refactor both into a single function with parameters, reducing your codebase by hundreds of lines and eliminating entire classes of bugs. Here's what that process actually looks like in practice. You start by mapping out the inputs and outputs of each function. Then you write down every decision point - every if statement, every loop, every branch. When you align these decision trees side by side, the common structure becomes visible almost immediately. In my experience, this takes about 10 to 15 minutes for functions under 50 lines each, and maybe 30 minutes for larger functions. The time investment pays off fast because you're not just solving one duplication problem - you're preventing future bugs in both code paths.

The Hidden Cost of Undetected Duplication

I learned about this the hard way. There was a user authentication module where the login check happened in two separate functions - one for web sessions and one for API tokens. The logic was identical except for the session storage mechanism. Six months after deployment, I found a security vulnerability in the password hashing comparison. Because the logic existed in two places, I had to patch both, test both, and deploy both. If I had recognized the commonality earlier and merged them, the fix would have taken minutes instead of hours. This is the real cost of not asking what do both of these functions have in common - it's not just messy code, it's security risk and operational drag. Another subtle issue involves testing coverage. When two functions share logic but exist separately, you tend to write tests for each one individually. But the shared core logic often sits in an untested middle ground. I've seen cases where the shared computation had a floating-point precision bug that both functions carried forward, and neither test suite caught it because the tests only verified the final output format, not the intermediate calculation steps.

Practical Techniques for Finding Commonality

The most reliable approach I use is abstract reduction. You take both functions and strip away everything that makes them unique to their specific context. Remove the database calls, the API endpoints, the UI formatting. What remains is the pure algorithm. If the remaining algorithm is the same, the functions are duplicates waiting to be merged. Here's a quick technique that works well in IDEs. Copy both functions into a diff tool or side-by-side editor view. Highlight the structural elements - the loops, the conditionals, the return statements. Ignore the literals and variable names. What you'll typically see is that 60 to 80 percent of the structural elements match while only the data access and output formatting differ. That 60 to 80 percent is your merge candidate. There's a boundary condition I want to mention specifically because it trips people up. Sometimes two functions share logic but shouldn't be merged. Consider a function that validates email format for a signup form and another that validates email format for a password reset flow. They might both call the same regex, but the signup version needs to check against a blocklist while the reset version doesn't. Merging them would either overcomplicate the reset flow or under-validate the signup flow. The rule of thumb is: merge when the difference is purely in data source or output format, not in business rules or constraints.

A counter-intuitive point that beginners miss is that identical code isn't always the best target for merging. Two functions that happen to produce the same output through different paths might actually be doing different things conceptually. For example, a function that calculates tax by looking up a rate table and another that calculates tax using a formula might produce identical results for current inputs, but they encode different business assumptions. Merging them could make future adjustments harder because you'd lose the semantic distinction between table-based and formula-based calculation. Always ask whether the shared behavior reflects shared intent, not just shared computation.

When This Approach Breaks Down

Function comparison isn't a silver bullet. It gets messy with deeply recursive functions, functions that depend heavily on external state, or functions that are intentionally polymorphic through inheritance or interfaces. I've encountered cases where two functions looked identical but one was memoized and the other wasn't, and merging them without preserving that difference caused performance regressions in high-throughput scenarios. The memoization wasn't part of the visible logic flow, so it didn't show up in my structural comparison. Another limitation involves functions with side effects. If Function A writes to a log file and Function B writes to a database, and the rest of their logic is identical, merging them means deciding which side effect is correct or creating a hybrid that does both. This often reveals that the functions weren't actually duplicates - they were solving slightly different problems that just happened to share a computational core. In these cases, extracting the shared computation into a third helper function is usually cleaner than merging the originals. If you're working with a very large codebase and need to find these patterns automatically, static analysis tools like PHPStan, Psalm, or similar linters for your language can flag duplicate code blocks. But these tools have their own blind spots - they typically compare text similarity rather than semantic equivalence, so they'll miss cases where the same logic is expressed through different control flow structures. Manual review using the techniques above remains the most reliable approach for complex cases.