3 ms·

The author rejects "Single Responsibility Principle" as “Pointlessly Vague" and offers instead the “Fits In My Head” principle. That is apparently better due to

The author rejects "Single Responsibility Principle" as “Pointlessly Vague" and offers instead the “Fits In My Head” principle. That is apparently better due to some hand wavy discussion which leaves no room to explain why same hand wavy justification would not apply to original. stopped reading after that.

jonnypotty 6y ago
I think it's saying simple, dogmatic rules aren't a good idea and don't reduce complexity. Trusting a dev to not write functions that are unreasonably complex IS a good rule if you spend the time to check and review code. Fitting your code around a load of "best practices" will basically always increase complexity because you've expanded the list of requirements the code has to conform to.
- sorokod 6y ago
  I don't think these principles are dogmatic, they rather give you a direction. Can you see that the rule "your code should have single responsibility" is more specific then "write simple code" ?
- herval 6y ago
  How is “fits in my head” not dogmatic, though? And how does fitting around practices necessarily increase complexity? If you’re a jr engineer used to write a mess of code to solve a problem, and have to decompose it following a set of principles, you may end up with something SIMPLER very easily. The whole point about principles is they lead to better outcomes. Problems arise when you confuse them with “rules that can’t be broken” or (as in this post’s case) just refuse to understand them and come up with your own half-assed heuristics - either to justify your code, for lack of experience, or just... to talk at a conference :-)
garethrowlands 6y ago
"This article isn’t about those principles, that will be my next post." The article does not present an alternative to SOLID, that's the next article.
- sorokod 6y ago
  ...and the linked slides
burade 6y ago
It's a good point though. Who decides what "one reason to change" is? a 10-line method could easily have hundreds of reasons to change.
- TuringTest 6y ago
  I think the point is that you wouldn't apply those hundreds of reasons all at once. But it your code is doing two things, you could end up having two reasons to change it at the same time.
- sorokod 6y ago
  You the programmer do. Do you expect everything to be automated by successive application of precise rules?

jonnypotty 6y ago

I think it's saying simple, dogmatic rules aren't a good idea and don't reduce complexity. Trusting a dev to not write functions that are unreasonably complex IS a good rule if you spend the time to check and review code. Fitting your code around a load of "best practices" will basically always increase complexity because you've expanded the list of requirements the code has to conform to.

sorokod 6y ago
I don't think these principles are dogmatic, they rather give you a direction. Can you see that the rule "your code should have single responsibility" is more specific then "write simple code" ?
herval 6y ago
How is “fits in my head” not dogmatic, though? And how does fitting around practices necessarily increase complexity? If you’re a jr engineer used to write a mess of code to solve a problem, and have to decompose it following a set of principles, you may end up with something SIMPLER very easily. The whole point about principles is they lead to better outcomes. Problems arise when you confuse them with “rules that can’t be broken” or (as in this post’s case) just refuse to understand them and come up with your own half-assed heuristics - either to justify your code, for lack of experience, or just... to talk at a conference :-)

garethrowlands 6y ago

"This article isn’t about those principles, that will be my next post." The article does not present an alternative to SOLID, that's the next article.

sorokod 6y ago
...and the linked slides

burade 6y ago

It's a good point though. Who decides what "one reason to change" is? a 10-line method could easily have hundreds of reasons to change.

TuringTest 6y ago
I think the point is that you wouldn't apply those hundreds of reasons all at once. But it your code is doing two things, you could end up having two reasons to change it at the same time.
sorokod 6y ago
You the programmer do. Do you expect everything to be automated by successive application of precise rules?