How can I avoid a function with too many unrelated responsibilities?

Look for steps that answer different questions or would change for different reasons. A function that reads a value, checks whether it is allowed, calculates a result, and formats a message may actually contain several jobs. A few lines that all contribute to one clear calculation, on the other hand, may belong together.

Try writing a short verb phrase for each group of steps. If the phrases are different—“normalize input,” “apply the rule,” “format the message”—and each group has a clear boundary, consider a helper. Then check whether the original function’s main flow becomes easier to scan. Splitting that makes readers jump around without improving the names or structure is probably not helping.

Assume this is an ordinary in-memory example and that the exact rules are placeholders. The point is how the work is organized, not what score rules a real program should use.

Before, one function might do all of this in sequence:

buildReport(scores):
    remove entries that should not be included
    calculate the summary from the remaining entries
    format the summary as report text
    return the report text

The name buildReport gives the overall goal, but each step has a different purpose. A clearer arrangement could be:

buildReport(scores):
    included = selectIncludedScores(scores)
    summary = calculateSummary(included)
    return formatReport(summary)

Now each helper name describes one part of the flow, and buildReport reads like a short outline. These names are illustrative; they do not prescribe particular filtering or calculation rules. If a helper would be just one opaque line, or its name would merely repeat the code, keep that step inline instead.

First ask whether the helper has a useful name and whether it belongs to this one function or has a wider use. In C#, a local function is a named helper declared inside a member and visible only there. Microsoft recommends that option when descriptive helper logic is needed by one member; use a regular method when multiple members need it, and a lambda when behavior is short and clear at its use site. It also advises keeping captured values few and obvious, or passing needed values explicitly to a static local function. These are C#-specific organization choices, not a universal test for finding unrelated responsibilities. [S1]

For any language, use the smallest boundary that makes the intent clearer. Don’t extract a helper just to reduce the line count. If it adds indirection, hides important details, or needs an awkward pile of parameters, reconsider the split. A helper can also be worthwhile when you want to name and reason about a distinct step, even if it is not reused.

Review the result from the caller’s point of view: can you understand the sequence without reading every implementation detail? Then inspect each helper in turn: does its name describe one job, are its inputs and output understandable, and did the split leave related logic awkwardly separated? Finally, compare the old and new behavior using the checks already available for your project. The example above doesn’t establish any particular score rule or guarantee that a refactor preserves behavior; verify that against your actual requirements.