Single Responsibility: the rule was never the argument, the example was

Nobody argues with SRP in principle. Every developer I’ve worked with agrees a function should do one thing. The argument is always at the example, whether a given function is one thing or six, and that is the part the rule itself doesn’t settle. Two things have done most of the work for me. The name. If you need an “and” to describe what the function does, it’s two jobs. Saying it out loud forces the description to be honest, and once you have said “it validates the order and then submits it” the extraction is obvious without anyone arguing about line counts. The actor question, from Clean Architecture: who pays when this changes. Two sets of people filing bugs against the same function is a boundary problem however short that function is. Parnas got to the same place in 1972 by listing the design decisions likely to change and giving each one a module that hides it. Length and complexity limits catch the same smell and I do run them, but they are proxies. A long function with a single reason to change is fine, and a short one serving two teams isn’t. This has mattered more since agents started writing the first draft. A developer reading a fuzzy boundary works the intent out from the surrounding code. An agent takes the boundary as given and builds on it. I write these up at https://prickles.org/tenet/single-responsibility-principle/F1 [https://prickles.org/tenet/single-responsibility-principle/F1] if the longer version is useful.