guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#58812] Coding style: similarly-named variables


From: Maxim Cournoyer
Subject: [bug#58812] Coding style: similarly-named variables
Date: Thu, 17 Nov 2022 15:34:27 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> * gnu/build/install.scm (evaluate-populate-directive): By default, error 
>>>> when
>>>> the target of a symlink doesn't exist.  Always ensure TARGET ends with "/".
>>>> (populate-root-file-system): Call evaluate-populate-directive with
>>>>  #:error-on-dangling-symlink #t and add comment.
>>>
>>> [...]
>>>
>>>> +  (define target* (if (string-suffix? "/" target)
>>>> +                      target
>>>> +                      (string-append target "/")))
>>>
>>> Maybe make it:
>>>
>>>   (let ((target (if …)))
>>>     …)
>>>
>>> so there’s only one ‘target’ in scope (and no ‘target*’); otherwise it’s
>>> easy to forget the ‘*’ and refer to wrong one.
>>
>> It's a pattern I've used at other places; I find it more hygienic to not
>> shadow existing variables; it signal to the reader "be careful, this is
>> not the same as the argument-bound one, though they are closely
>> related".
>
> I don’t buy it.  :-)  The reader might be careful yet end up using the
> “wrong” variable.  As long as the “wrong” variable has no use, I think
> it’s best to shadow it so that mistakes cannot happen.

I'm surprised you're not buying it, given we're writing Scheme in a more
functional style, and mutating same-named variables clearly goes against
that style :-).

> Of course the details vary depending on context, but I think we should
> not start introducing this pattern in different places.  Perhaps
> something to discuss and codify under “Formatting Code”?

That's more of a coding style guidelines than "formatting" code (when I
read "formatting", I think of a mechanical process like 'guix style' or
'rust-fmt' can do), but yes, that could be nice to have.  Better yet,
something basic to share across the whole Guile/Scheme community and
include in the Guile user manual, like Python has PEP 8 they can refer
to, to save every Guile/Scheme project from having to reinvent the
wheel.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]