4 ms·

> Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag. vs > Needless Repetition.

by bsza 5y ago

lmm 5y ago
Look more carefully, there's no contradiction. Splitting a method into several independent methods doesn't mean you repeat yourself.
- bsza 5y ago
  The flag check could be deep within a loop, how would you split it then without repeating the whole method?
  - asimpletune 5y ago
    Using map?
  - lmm 5y ago
    Make the loop operation something that's passed into the method. Or maybe replace the flag with polymorphism if there's some logical value that it really belongs on.
    - 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.

> Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag. vs > Needless Repetition.

by bsza 5y ago

> Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag. vs > Needless Repetition.

lmm 5y ago

Look more carefully, there's no contradiction. Splitting a method into several independent methods doesn't mean you repeat yourself.

bsza 5y ago
The flag check could be deep within a loop, how would you split it then without repeating the whole method?
- asimpletune 5y ago
  Using map?
- lmm 5y ago
  Make the loop operation something that's passed into the method. Or maybe replace the flag with polymorphism if there's some logical value that it really belongs on.
  - 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.