是否需将循环内的occ<10判断逻辑封装为独立方法？

Great question—this is exactly the kind of nuanced call that separates clean, maintainable code from just functional code, and it ties directly to the single responsibility principle (SRP) and readability that Clean Code hammered home. Let’s break this down based on the book’s principles and real-world practice:

When You Can Skip Encapsulation #

If this occ < 10 check only appears once in your code, and the context makes its purpose immediately clear (e.g., you’re right in the middle of logic that formats occurrence counts with leading zeros), keeping it inline is totally fine.

Readability is king here—someone reading if(occ < 10) will instantly grasp what’s happening without needing to jump to a method definition. For super-simple, single-use logic, adding a method call can actually create unnecessary cognitive overhead. The "short method" rule in Clean Code isn’t about splitting every line into a method; it’s about ensuring each method does one clear thing. A single inline condition like this doesn’t violate that.

When Encapsulation Is a Great Idea #

You’ll want to wrap this logic into a method if any of these are true:

• The check is reused multiple times: If you find yourself writing occ < 10 in 3+ places, encapsulating it follows the DRY (Don’t Repeat Yourself) principle. Changing the threshold later (e.g., from 10 to 15) only requires updating one method instead of hunting down every instance of the condition.
• The check has a distinct business meaning: If this isn’t just a random number—say it’s a rule like "occurrence counts under 10 need leading zeros for reporting consistency"—a well-named method makes that intent explicit. For example, renaming your method to needsLeadingZeroForOccurrenceCount(occ) turns a vague condition into self-documenting code. Anyone reading the code will understand why you’re checking the value, not just what you’re checking.
• The surrounding logic is getting cluttered: If your loop is already handling multiple responsibilities (iterating, transforming data, validating), splitting out the condition check (and even the string formatting logic) helps keep each piece focused. For example, you could go a step further and wrap the entire formatting logic into one method:

  private String formatOccurrenceEntry(String current, int occ) {
      return occ < 10 ? current + "0" + occ : current + occ;
  }
  

  Then your loop becomes just values.add(formatOccurrenceEntry(current, occ))—clean, concise, and every part of the code has a single job.

Key Takeaway on Method Length #

Clean Code’s advice about short methods isn’t about arbitrary line counts—it’s about ensuring each method does one thing, and that thing is obvious from the method name. A 1-line method is fine if it encapsulates a meaningful concept; a 10-line method is okay if every line serves the same clear purpose.

So in your case: if the occ < 10 check is a one-off with obvious context, skip the method. If it’s reused, has business meaning, or helps declutter your loop, absolutely encapsulate it.

内容的提问来源于stack exchange，提问作者Ryan Sangha