Clean Code Cookbook

Chapter 11. Bloaters

The purpose of software engineering is to control complexity, not to create it.

Pamela Zave in Programming Pearls, 2nd Edition by Jon Bentley

11.0 Introduction

Bloaters are unavoidable when your code grows and many people collaborate. They often don’t cause performance problems, but they damage maintainability and testability, preventing good software from evolving. The code becomes unnecessarily large, complex, and difficult to maintain, often due to the inclusion of unnecessary features, poor design choices, or excessive repetition. Code gets bloated in small steps and then you notice you have a big mess. You don’t write long methods, but maybe you add small portions and a teammate adds some more, and so on. This is a kind of technical debt (see Chapter 21, “Technical Debt”) that is easier to reduce with state-of-the-art automated tools.

11.1 Breaking Too Long Methods

Problem

You have a method with too many lines of code.

Solution

Extract the long method into smaller pieces. Break complex algorithms into parts. You can also unit-test these parts.

Discussion

Long methods have low cohesion and high coupling. They are difficult to debug and have low reusability. You can use this recipe to break structured libraries and helpers into smaller behaviors (see Recipe 7.2, “Renaming and Breaking Helpers and Utils”). The amount of lines depends on the programming language, but 8 to 10 lines should be enough for most of them.

Here’s a long method:

function ...