This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: style convention: /*foo_p=*/ to annotate bool arguments

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.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]