Hi Jeff,
(Sorry I didn't reply sooner, I was OOO.)
On 11/08/2015 11:17 PM, Jeff Law wrote:
> On 11/07/2015 07:31 AM, Pedro Alves wrote:
>> Hi Richard,
>>
>> Passerby comment below.
>>
>> On 11/07/2015 01:21 PM, Richard Sandiford wrote:
>>> -/* Lookup the identifier ID. */
>>> +/* Lookup the identifier ID. Allow "null" if ALLOW_NULL. */
>>>
>>> id_base *
>>> -get_operator (const char *id)
>>> +get_operator (const char *id, bool allow_null = false)
>>> {
>>> + if (allow_null && strcmp (id, "null") == 0)
>>> + return null_id;
>>> +
>>> id_base tem (id_base::CODE, id);
>>
>> Boolean params are best avoided if possible, IMO. In this case,
>> it seems this could instead be a new wrapper function, like:
> This hasn't been something we've required for GCC. I've come across
> this recommendation a few times over the last several months as I
> continue to look at refactoring and best practices for codebases such as
> GCC.
FWIW, GDB is in progress of converting to C++ and we're pulling in
GCC's C++ conventions as reference, so I thought I'd see what the GCC
community thought here.
>
> By encoding the boolean in the function's signature, it (IMHO) does make
> the code a bit easier to read, primarily because you don't have to go
> lookup the tense of the boolean). The problem is when the boolean is
> telling us some property an argument, but there's more than one argument
> and other similar situations.
There's more than one way to avoid boolean parameters.
If you have more than one of those, the boolean trap is even
worse IMO. In such cases, enums can help make things clearer for
the reader. E.g.:
foo (true, false);
foo (false, true);
vs:
foo (whatever::value1, bar::in_style);
I think that internal helper functions defined close to
their usage end up being OK to use booleans, while if you have
a API consumed by other modules it pays off more to try to
avoid the boolean trap.
Anyway, sorry for the noise. I know there are bigger fish to fry.
Thanks,
Pedro Alves
