This is the mail archive of the gcc@gcc.gnu.org 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 4 October 2016 at 12:39, Bernd Schmidt wrote:
> On 10/04/2016 12:41 PM, Jonathan Wakely wrote:
>>
>> On 4 October 2016 at 10:21, David Brown wrote:
>>>
>>> On 04/10/16 01:48, Martin Sebor wrote:
>>>>
>>>> In a recent review Jason and I discussed the style convention
>>>> commonly followed in the C++ front end to annotate arguments
>>>> in calls to functions taking bool parameters with a comment
>>>> along the lines of
>>>>
>>>>   foo (1, 2, /*bar_p=*/true);
>>
>>
>> I like this convention at the call-site, otherwise "true" or "false"
>> doesn't tell you much and you have to look at the declaration.
>
>
> Isn't that the case for "1" and "2" too?

Yes, definitely!

In real cases we're unlikely to use literals for more than one or two
args, so you'd have:

foo (type, func, true);

where the variable names (hopefully) convey some more information, and
the surrounding context tells you what those variables hold anyway. So
it's literals that aren't clear what they mean at the call site.

As Nathan said, it's more of a problem when you have multiple
arguments that are a string of literals. I would say even for one arg
it can save you having to check the function declaration if it's a
function you aren't familiar with. Does "true" mean "do the optional
thing" or "skip the optional thing"?


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