bug#48264: [PATCH v3 03/15] Add and use BUFFER_DEFAULT_VALUE_P

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@catern.com>
>> Cc: 48264@debbugs.gnu.org
>> Date: Fri, 07 May 2021 08:49:59 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> From: Spencer Baugh <sbaugh@catern.com>
>> >> Date: Thu,  6 May 2021 17:33:34 -0400
>> >> Cc: Spencer Baugh <sbaugh@catern.com>
>> >> 
>> >> This makes the code more clear and allows us to more easily change how
>> >> this property is determined.
>> >
>> > Does it?  Can you explain why you think so?  It looks like we are
>> > replacing clear code with an equally clear different code.
>> 
>> Well, "if (idx > 0)" as a conditional requires a fair bit of digging in
>> the implementation of DEFVAR_PER_BUFFER variables to understand.  On the
>> other hand, "if (BUFFER_DEFAULT_VALUE_P (offset))" is immediately clear:
>> We're checking if this variable has a default value.
>
> It's the other way around here: the test "if (idx > 0)" is clear,
> whereas "if (BUFFER_DEFAULT_VALUE_P (offset))" makes me go look up the
> definition of the macro, because the name is not expressive enough,
> and the argument "offset" doesn't help, either.

Sure; what about the name "BUFFER_VAR_HAS_DEFAULT_VALUE_P"?  More
verbose, but I think that makes the functionality sufficiently clear
that one won't need to look at the definition of the macro.

"idx > 0" is only clear if one has memorized how all the different
pieces of DEFVAR_PER_BUFFER metadata (such as the index) work.  But I
don't think a casual reader would have done that.