On 10/04/2016 11:41 AM, Jonathan Wakely wrote:
>
> IMHO even better is to not use bool and define an enumeration type, so
> the call site has something unambiguous like foo (1, 2, yes_bar) or
> foo (1, 2, no_bar).
Whole-heartily agreed. A quite recent example. On gdb-land, a
patch was proposing:
+ observer_notify_user_selected_thread_frame (1, 1);
(1 is true/boolean, this was a C-compatible patch.)
while the final landed version changed to:
+ observer_notify_user_selected_context_changed (USER_SELECTED_THREAD
+ | USER_SELECTED_FRAME);
At least the original version provided a hint of what which
parameter meant in the function's name ("thread", "frame") though at
least USER_SELECTED_INFERIOR will be added quite soon, and likely
others "user-selected" context scopes will be added later too.
With the boolean approach, we'd either end up with an increasingly long
function name:
observer_notify_user_selected_inferior_thread_frame_what_not (1, 1, 1, 0, 1);
at which point we'd likely remove the "parameter self-description" from the
function name, and end up with _really_ unclear call sites:
observer_notify_user_selected_context (1, 1, 1, 0, 1);
/*foo_p=*/ -style comments would help clarify the intent at the call
sites, but then the compiler won't catch mistakes for you. Enums are
clearly superior, at least compared to multiple boolean parameters, IMO.
Thanks,
Pedro Alves
