[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Convention for new “guix style“?
Re: Convention for new “guix style“?
Wed, 22 Dec 2021 16:52:33 +0100
We are consistent with what we already said on IRC. ;-)
On Wed, 22 Dec 2021 at 15:10, Jelle Licht <email@example.com> wrote:
>> --8<---------------cut here---------------start------------->8---
>> (list libx11 libiberty ;needed for objdump support
>> zlib)) ;also needed for objdump support
>> --8<---------------cut here---------------end--------------->8---
> Yuck indeed!
Therefore, the tool requires a first “exception” for this case.
(list foo bar
baz ;for tests
The tool already contains an “exception” for this other case.
(list julia-chainrulestestutils julia-finitedifferences julia-nanmath
>> 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.
> You seem to be putting the cart before the horse here; we should not let
> our (lack of) tooling determine our styling preferences.
Hum, I do not know. Maybe. For sure, I write my grocery list as:
apple orange beer flour
but all the flavours are equal. :-)
>> Consider the case,
>> (list bar foo1 foo2 foo3 foo3 foo4))
>> then another ’baz’ inputs is added, do we end with,
>> (list bar foo1 foo2 foo3 foo3 foo4
>> to minimize and ease reading the diff, or do we end with,
>> (list bar
> The second, ideally.
>> ? And the converse is also true, consider the case just above and what
>> happens if foo1, foo2 and foo3 are removed.
> Everything gets put on a single line again.
This makes the diffs harder to deal with. Because one part of the issue
is about comparing revision A with revision B, not just the read the
list at one specific revisin. Going back and forth to multi and single
line is error-prone, IMHO.
I agree that 1. comparing does not happen so frequently but still, and
2. it does not happen to so many packages but still.
For sure, S-Diff presented by Arun  at last FOSDEM 2021 would help.
AFAIK, this kind of tool is not ready for day-to-day usage and not yet
integrated with Git.
>> One item per line solves all these boring cosmetic questions.
> To be fair, any policy that can be automatically applied solves those
> very same boring cosmetic questions. I agree that whatever style we end
> up with, we should be able to automatically apply it.
I agree that tools can help. However, at some point, we effectively
read and the default policy should ease this reading, even with plain
text without any tools.
«Automatically apply it» is not straightforward. We already have a
great tool “guix lint” and it is not automatically applied.
For sure, I also think that automatic tools is the direction to go, for
sure I want more automation. And “guix style” is a step toward fixing
FWIW, I do find it strange that Lisp projects, despite using a
minimal-syntax language (mostly in order to conserve its regular
tree structure), do not usually automatically format source code
as they check in, but Go projects, using the prime example of an
irregular C-like language, DOES usually use code formatters
automatically when checking in. That is some strange reversal
of strengths that I wouldn't have expected.
>> This would avoid “cosmetic” changes when adding/removing inputs and/or
> This is not a convincing argument to me; I very much doubt that we have
> that many packages that switch back and forth between having <= 4 and >
> 4 inputs constantly. That is not to say that I think we won't see it
> happen; I just don't think it happens often enough to warrant what you
> are proposing :-).
As I am pointing, comment is an issue, obscure diff is another, 4
long-names which splits into 2 lines is another. These 3 cases are just
things that annoyed me reviewing OCaml update and packaging Julia, after
one week or so using this new style.
(Issue is a strong word for this bikeshed. ;-))
As a good coding style says: «Don't put multiple inputs on a single line
unless you have something to hide». ;-)
However, I do not see the advantages for one line. :-)
> I agree, so here's a counter-proposal: adjust the convention and guix
> style to leave inputs-with-comments alone. Only put inputs on one line
> when there are fewer than N items (configurable, but for now 5), as well
> as no comments on any of the lines.
You are proposing to implement more “rules“. :-) Why not, but it appears
to me a French mindset ;-) add more cases and layers instead of just
simplify with one unique as simple as possible rule.