Skip To Content
Clean Code


Classes are templates for creating objects in object-oriented programming. They appear frequently in back-end programming and lately in the front-end too.

Organization #

Classes should start with a list of variables, and be ordered as such:

Encapsulation #

Variables and functions should be private unless they're the functionality other parts of the program need, or they're needed for a test.

Make Them Small #

Classes should be small, and the best measure is not by physical lines but by responsibilities.

Single Responsibility #

Go by the Single Responsibility Principle (SRP), where a class or module should only have one responsibility or reason to change. Any extra responsibilities should be abstracted to other classes or modules.

Remember to follow this concept after you first get code working. The first working version often has too many responsibilities, so even though it works it needs to be refactored to adhere to the SRP.

If you worry lots of small classes are tougher to understand than a large one, you're wrong. The former may take up more lines but has just as many moving parts. It also:

Cohesion #

Aim for classes to have a small number of instance variables, and the class methods should manipulate one or more of these variables. The more instance variables a method manipulates, the more cohesive it is. Perfect cohesion is impossible, but high cohesion keeps methods and instance variables co-dependent and working as a logical whole.

If some instance variables are only changed by a subset of methods, it's a sign it should be another class. Following cohesion also encourages smaller classes.

Organizing for Change #

Most code systems need continuous change, and each change brings risk it'll break. Classes should be written to reduce the risk of changes breaking them.

When making changes, note the difference between adjustments to specific functionality and opening up the entire class. The more widespread the change is, the more you should consider refactoring the class as you change it. When classes are already broken in small, logical units, you're less likely to need these refactors.

In an ideal system of change, classes are open for extension (like via subclassing) but closed for modification.

Isolating from Change #

Some classes rely on concrete details, like hardcoded URLs or keys. These concrete details should be abstracted away.