Re: Convention for new “guix style“?

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:
> [...]
> --8<---------------cut here---------------start------------->8---
>     (inputs
>      (list libx11 libiberty ;needed for objdump support
>            zlib))                       ;also needed for objdump
> support
> --8<---------------cut here---------------end--------------->8---
> 
> when the comments apply to only one line as it was:
> 
> --8<---------------cut here---------------start------------->8---
>      `(("libx11" ,libx11)
>        ("libiberty" ,libiberty)               ;needed for objdump
> support
>        ("zlib" ,zlib)))                       ;also needed for
> objdump support
> --8<---------------cut here---------------end--------------->8---
> 
> Other said, this looks better:
> 
> --8<---------------cut here---------------start------------->8---
>     (inputs
>      (list libx11
>            libiberty ;needed for objdump support
>            zlib))    ;also needed for objdump support
> --8<---------------cut here---------------end--------------->8---
> 
> Obviously, we could come up a rule depending on comments, numbers of
> inputs, length, etc.  It was not the case with the old style when
> nothing prevented us to do it.  Because one item per line is, IMHO,
> easier to maintain.
For me personally, this illustrates two things.  First, the weakness of
line comments over preceding line comments ad second the verbosity of
old input style.  You could easily write 
  (list libiberty zlib) ; for objdump
in the new style, which you couldn't before.  Therefore, I wouldn't
mandate a "one line per input" restriction, as the only reason it was
ever imposed was a historical limitation.

> Consider the case,
> 
>     (inputs
>      (list bar foo1 foo2 foo3 foo3 foo4))
> 
> then another ’baz’ inputs is added, do we end with,
> 
>     (inputs
>      (list bar foo1 foo2 foo3 foo3 foo4
>            baz))
> 
> to minimize and ease reading the diff, or do we end with,
> 
>     (inputs
>      (list bar
>            baz
>            foo1
>            foo2
>            foo3
>            foo3
>            foo4))
> 
> ?  And the converse is also true, consider the case just above and
> what
> happens if foo1, foo2 and foo3 are removed.
> 
> One item per line solves all these boring cosmetic questions.
> 
> Therefore, I propose to always have only one item per line.  To be
> concrete, for one item:
> 
>   (inputs
>    (list foo))
> 
> or not
> 
>   (inputs (list foo))
> 
> And for more than one item:
> 
>   (inputs
>    (list foo
>          bar))
> 
> This would avoid “cosmetic” changes when adding/removing inputs
> and/or comments.
In my personal opinion, everything else being equal, changes to
inputs/native-inputs/propagated-inputs should (almost) always be seen
as changes to the field, as would be documented in the ChangeLog.

I think the usual scheme coding guidelines also apply well to inputs,
e.g. inline short stuff, but don't do funky things when the lines grow
unnecessarily long.

Now I am putting aside the issue of tooling here, because I think that
humans ought to be able to look at the diff and see that something's
wrong and correct it, but as others point out an "I don't touch
comments" approach would be very fine by me.

Cheers