[cjfd]

'rule of 3s' is way too simplistic. It is on the beginner level. 3 is an arbitrary number anyway. It can be any other number depending on the situation. And creating an abstraction from only one use can be valid. In particular this happens if something gets a bit big while talking to too many other things. E.g., a function receives RPC while also doing something with a piece of hardware, and both of these things are a bit non-trivial. These two things should then not be mixed even when it is the only function doing these two things. I will say though, that creating an abstraction from one example one should expect that some future improvements to the abstraction will most likely be necessary.

[vacuity]

I like to think of it as two intertwined rules:

  a concrete problem domain has an ideal solution with ideal abstractions for its purposes
  seek to understand your problem domain to a reasonable extent before writing hard-to-change code

Of course, we don't understand the problem domain perfectly from the start, and neither do we write perfect programs from the start. It's an iterative process of optimization, where you alternatively work on a specific understanding or work on the understanding. Everyone has to figure out that balance for themselves.

[coldtea]

>'rule of 3s' is way too simplistic. It is on the beginner level. 3 is an arbitrary number anyway.

That's precisely why it's useful.

"On your discretion" would just lead to endless bikeshedding - as having a useful discretion requires that you are already advanced enough to not need such advice.

It's not that new devs really understand three to be some special number either: just a useful heuristic, which can be 2 or 4 or 5 if needed.