So Uncle Bob, talking about the Single Responsibility Principle, writes: "When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function." blog.cleancoder.com/uncle-bob/2014/05/08/…

That's pretty hard to apply when you're writing code where you yourself are deciding all of the requirements, or code which is never going to change. :D

Granted, "code which is never going to change" is... somewhat rare. But I have written such code.

Suppose you want to write a function that translates an unsigned 32-bit integer to a signed 32-bit integer, preserving order. Well, there's really only one algorithm to do this, and there's really only one way to implement that algorithm, so once you write this code, you're never going to need to change it.

If you're supposed to "gather together the things that change for the same reasons, separate those things that change for different reasons," what are you going to do with a thing that's never going to change for any reason?

But in general, I've found it best to completely ignore anything that “Uncle Bob” says.

Much of his advice, where sensible, is mostly sensible in a very enterprisey context. A lot of software happens in that context, but a lot of software also doesn't

Your integer conversion routine is a great example of a cute CS problem, but that's a completely different context from enterprisey business logic where the single-stakeholder advice does make sense

(Incidentally, the most impactful thing I did while working on enterprise software was fixing a horrible number conversion bug.)