Section 9.7/9.8

[Pierre Arnaud]

I would argue that a public method should be deep, and that internal implementation methods should be broken up to make the code as easy as possible to read.

In my experience, I tend to extract small chunks of code (which would require a comment to make their goal explicit) into functions with a self-describing name. And if done right, this makes the code easier to reason about, letting the reader dig into the details gradually, based on their need to understand the underlying details.

Pierre

Envoyé de mon iPhone

[John Ousterhout]

On Mon, Dec 22, 2025 at 11:49 AM 'Pierre Arnaud' via software-design-book <software-d...@googlegroups.com> wrote:

I would argue that a public method should be deep, and that internal implementation methods should be broken up to make the code as easy as possible to read.

In my view the best way to make code "as easy as possible to read" is to use deep interfaces. The benefits of deep interfaces apply just as well with private methods as with public ones.

In my experience, I tend to extract small chunks of code (which would require a comment to make their goal explicit) into functions with a self-describing name. And if done right, this makes the code easier to reason about, letting the reader dig into the details gradually, based on their need to understand the underlying details.

I'm not a fan of using "self-describing" function names as an alternative to comments. For more on this topic, see my online discussion with "Uncle Bob" Martin:

 https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md

-John-