Rather than writing a monolithic code, I've been taught to find the parts of code which can be reused (in the same code or in others) and create a function based on them, which should perform "one and only one" task. Is there a term for this programming style? Modularization? It's definitely not functional programming, because that's something different (even though you do tend to define functions and reuse them in functional programming too).

  • 3
    Usually this is just called good factoring. There is a substantial number of practitioners who consider some of the more popular Design paterns (e.g. "Bridge") just instances of good factoring. – Kilian Foth Nov 9 '18 at 14:42
  • This is one pillar of Unix commands. – mouviciel Nov 10 '18 at 12:13

The practice of making smaller (potentially reusable) parts is called functional decomposition. This is a general engineering terminology that is not limited to software engineering.

An even more disciplined practice is the do-one-thing rule rule: Not only are complex functions decomposed in smaller parts, but "Functions shall do one thing only and do it well".

This style alone doesn't have its own name as far as I know. However, together with a couple more principles and rules, it is part of Clean Code practices.

Caution: There is a frequent confusion between do-one-thing rule and the single responsibility principle (SRP). This is because both are described in R.C.Martin's book, Clean Code, and the SRP naming is unfortunate and confusing. SRP is not about functionality, but about reasons to change. This is best explained by Uncle Bob himself in this article


I know at least 3 different principles which fit to your description:

  • The "Single responsibility principle" (SRP, the "S" in SOLID) refers to what you mentioned by functions with "one and only one" task.

  • The "Don't repeat yourself" principle (DRY) is applied when you don't copy code for reusage, but refactor it into a function instead.

  • The "Single level of abstraction" principle (SLA) means not to use "reusage" as the one and only measure for such refactorings, but also use functions as building blocks of a - surprise - certain level of abstraction.

If I got you right, these three principle together should cover what you had in mind.

And yes, the term "modularization" fits also, but more at the level of modules, which is typically coarser than just functions.

  • Thanks! DRY is what I had heard, but couldn't recall. SRP is what also the other answer refers to. I don't understand what SLA is - could you please elaborate a bit? And yes, I thought modularization was higher level - that's why I asked here. The term I heard was definitely DRY, but I'm interested in the other two too. – DeltaIV Nov 9 '18 at 15:33
  • 1
  • I think there is a terminological confusion between do-one-thing rule and the SRP. The SRP is about reason to change and not about the functionality offered, as explained by uncle Bob here. – Christophe Nov 9 '18 at 17:18
  • @Christophe: well, it seems my guess what the OP had in mind when talking about "one and only one" was not too bad. – Doc Brown Nov 9 '18 at 17:22
  • @DocBrown :-) here I fully agree ! And the remaining points are all very relevant – Christophe Nov 9 '18 at 17:23

The issue is that "separating code" is too broad a topic for it to have a specialized name. For example, most SOLID implementations revolve around introducing additional separation in your code, but doing so in many varied ways, for many varied reasons.
And SOLID is by no means the only guideline here, although it seems to be the most prevalent one in OOP.

If anything, the difficulty is not in separating the code, but rather how to loosely (and of course correctly) connect the now separate pieces.

Purely semantically, I tend to refer to code separation as compartmentalization:


To separate into isolated compartments or categories

This has some relation to the fields of engineering:

When referring to engineering, compartmentalization is the general technique of separating two or more parts of a system to prevent malfunctions from spreading between or among them. This entails the breaking up of a project or problem into sub classes and sub categories, with the intention of simplifying the task at hand, or to efficiently distribute it amongst a number of teams or people.

and information security:

Compartmentalization, in information security, whether public or private, is the limiting of access to information to persons or other entities on a need-to-know basis to perform certain tasks.

While this is, as far as I'm aware, not an established programming term, its meaning seems clear from both the dictionary definition and its application in similar fields.

create a function based on them, which should perform "one and only one" task

"One and only one task" is effectively the Single Responsibility Principle (the S in SOLID) at play.

  • 1
    @DeltaIV: I think my answer update already covers that :) If the main intent is "one task at a time" it's predominantly the Single Responsibility Principle at play. It is by far the broadest and simplest guideline in SOLID, whereas the others are more particular to specific use cases (and one could e.g. argue that Liskov and Interface segregation are really the same, only that the former focuses on classes and the latter on interfaces). – Flater Nov 9 '18 at 14:56
  • @downvoter: care to elaborate? – Flater Nov 9 '18 at 14:57
  • 1
    Please reread Clean Code: SRP has nothing to do withe the do-one-thing rule (see my comment on the other answer). I'd add that compartmentalisation is about separation of concerns. I think OP was more interested in functional decomposition. – Christophe Nov 9 '18 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.