> Basically, if you have a function takes a boolean in your API, just have two functions instead with descriptive names.
Yeah right like I’m going to expand this function that takes 10 booleans into 1024 functions. I’m sticking with it. /s
Yeah right like I’m going to expand this function that takes 10 booleans into 1024 functions. I’m sticking with it. /s
Tons of well-written functions have many more potential code paths than that. And they're easy to reason about because the parameters don't interact much.
Just think of plotting libraries with a ton of optional parameters for showing/hiding axes, ticks, labels, gridlines, legend, etc.
engage_turbo_encabulator(True, False, True, False, True, False, True, False)
engage_turbo_encabulator(
enable_hydrocoptic=True,
allow_girdlespring=False,
activate_marzelvanes=True,
sync_trunnions=False,
stabilize_panametric=True,
lock_detractors=False,
invert_logarithms=True,
suppress_lunar_wane=False
)
If this was my function I would probably make the parameters atrributes of an TurboEncabulator class and add some setter methods that can be chained, e.g. Rust-style:
encabulator = (
TurboEncabulator.new()
.enable_hydrocoptic(True)
.allow_girdlespring(False)
.enable_marzelvane_activation(True)
.enable _trunnion_syncing(False)
.enable_param_stabilization(True)
.enable_detractor_locking(False)
.enable_logarithm_inversion(True)
.enable_lunar_wane_supression(False)
.build()
)I absolutely agree named arguments are the way to go. But my comment wasn't in the thread about that.