Skip to main content

Bloaters

The first category of code smells we'll explore is Bloaters - one of the most common signs you'll find in any codebase. Bloaters go directly against the fundamental principle of Clean Code that Sandi Metz emphasized in her talk "All the Little Things":

Make Smaller Things. - Sandi Metz, 2014

When asked about the best way to write better object-oriented code, Sandi's advice is simple: make smaller things. Make smaller classes, smaller methods, and let them know as little about each other as possible.

Why Size Matters​

Size can be evil, and this limitation comes from the human brain. Code isn't only meant for computers to execute - it's also for developers to read. The amount of information and concepts humans can process at once is strictly limited.

Unlike servers that can run multiple threads, developers cannot do the same mentally. That's why following guidelines for file length and line count is crucial for maintainable code.

The Nature of Bloaters​

Bloaters make software difficult to work with. They represent pieces of code that have grown so large they become hard to read and maintain.

Typically, bloaters don't happen overnight but accumulate over time as your codebase grows. This is usually a slow process:

  1. Code starts small and well-isolated
  2. New functionality gets added incrementally
  3. Code becomes more general to handle edge cases
  4. No developer points out the growing problem
  5. Eventually, the code becomes unwieldy

The good news? If you can identify bloater smells in your components, you can make your code cleaner with the same kind of gradual changes that caused the problems in the first place.

Types of Bloaters​

Long Method​

Generally, any method longer than ten lines should be considered suspicious. It may be responsible for more tasks than it should be.

Key indicators:

  • Methods exceeding 10+ lines
  • Multiple levels of abstraction in one method
  • Complex conditional logic
  • Scrolling required to see the entire method

Large Class​

A class that contains too many fields, methods, and lines of code. Based on experience, classes over 500 lines warrant suspicion.

Key indicators:

  • Classes with 500+ lines
  • Multiple unrelated responsibilities
  • Low cohesion between methods
  • Difficulty understanding the class's main purpose

Primitive Obsession​

The excessive use of basic data types (strings, integers, booleans) to represent concepts or entities that should be objects.

Key indicators:

  • Using strings for everything (IDs, statuses, categories)
  • Magic numbers scattered throughout code
  • Complex validation logic for primitive values
  • Missing domain-specific behavior

Long Parameter List​

When a function or method has too many parameters, making it difficult to understand and use.

Key indicators:

  • Methods with 4+ parameters
  • Boolean flags as parameters
  • Related parameters that should be grouped
  • Difficulty remembering parameter order

Data Clumps​

Groups of variables that always appear together and should be turned into their own object.

Key indicators:

  • Same group of parameters in multiple methods
  • Variables that are always passed together
  • Related data without encapsulation
  • Repeated parameter patterns

The Human Cost of Bloaters​

Bloaters create several problems:

  • Cognitive Overload: Developers spend more mental energy understanding what code does
  • Reduced Productivity: More time reading and deciphering instead of building features
  • Increased Bugs: Complex code is harder to reason about and test
  • Poor Maintainability: Changes become risky and time-consuming
  • Team Friction: New developers struggle to understand and contribute

The Gradual Solution​

Dealing with bloater code smells, like most refactoring, is best done one small step at a time. The key is to:

  1. Identify the smell - Recognize the specific bloater pattern
  2. Choose the right refactoring technique - Each smell has proven solutions
  3. Make small, incremental changes - Avoid big-bang refactoring
  4. Test continuously - Ensure behavior remains unchanged
  5. Repeat the process - Gradually improve code quality

Prevention is Better Than Cure​

While we'll explore specific refactoring techniques for each bloater type, the best approach is prevention:

  • Code reviews - Catch bloaters before they grow
  • Regular refactoring - Don't let technical debt accumulate
  • Clear coding standards - Establish size limits and guidelines
  • Automated tools - Use linters and metrics to catch problems early

References​