2 ms·
The second one is impractical because the number of classes you'd need would increase exponentially with each added flag. The first one clashes with > Prevent
by bsza 5y ago
The second one is impractical because the number of classes you'd need would increase exponentially with each added flag. The first one clashes with
> Prevent over-configurability,
because you're accepting an infinite range of possible callback methods instead of asking a simple yes/no question.
I don't get why this rule even exists, actually. If you take three boolean arguments, that's not okay, but if you wrap them all into a configuration object and pass that instead, that's suddenly... okay?
- lmm 5y ago> the number of classes you'd need would increase exponentially with each added flag. Only if you actually call it exponentially many different ways, which seems unlikely. > I don't get why this rule even exists, actually. If you take three boolean arguments, that's not okay, but if you wrap them all into a configuration object and pass that instead, that's suddenly... okay? Three or four booleans are not something semantically meaningful that you can reason about. Five or six classes representing the cases that actually occur in your program, that's something you can understand. Often passing a callback function is too. Boolean flags fall into a hole in the middle somehow, probably because of the exponentially many possible combinations; they look like a finite set of possibilities, but in practice you almost certainly haven't tested all the cases and a lot of them probably don't make sense.