Peter Maydell <peter.mayd...@linaro.org> writes:
> On Mon, 6 Mar 2023 at 18:29, Marc-André Lureau
> <marcandre.lur...@gmail.com> wrote:
>>
>> Hi
>>
>> On Mon, Mar 6, 2023 at 8:06 PM Peter Maydell <peter.mayd...@linaro.org>
>> wrote:
>> >
>> > On Mon, 6 Mar 2023 at 12:33, <marcandre.lur...@redhat.com> wrote:
>> > >
>> > > From: Marc-André Lureau <marcandre.lur...@redhat.com>
>> > >
>> > > Make the resulting code even prettier, if possible.
>> >
>> > This seems to be a bit short on rationale. This is generated
>> > code, so in general nobody is going to be reading it, and
>> > running clang-format on it every time we generate code feels
>> > like it would be a bit of a waste of cycles...
>>
>> With this reasoning, why do we care about indentation of generated code at
>> all?
>>
>> I think it still makes sense, because you have many reasons to read
>> through it eventually, and making it a bit more friendly helps.
>
> Yeah, sometimes you have to read through it, so not printing
I have to read it frequently enough to make ugly code painful.
> it all one one long line is helpful. But it's a tradeoff --
> "make it basically kinda readable by tracking indent level" is
> easy and quick; running the whole output through a pretty-printer
> is more expensive and doesn't improve the output by very much
> over what we already have. (If I'm wrong about that last part,
> it would be useful for the commit message to give an example
> of currently unreadable output that clang-format makes more usable.)
Tracking indent level is certainly quick, but it can take a bit of
effort. In review of v3, I asked for more effort, and Marc-André
floated the idea of leaving the job to readily available clang-format
instead:
ok, I improved the indentation a bit.
However, I think it would be simpler, and better, if we piped the
generated code to clang-format (when available). I made a simple patch
for that too.
My reply was
Piping through indent or clang-format may well give us neater results
for less effort.
We might want to dumb down generator code then.
Message-ID: <87356yq9rs....@pond.sub.org>
https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06311.html
v4 no longer contains the indentation issue that triggered this
exchange. Let's treat this patch as if it was separate, so it doesn't
delay the remainder of the series.
You're certainly right to ask for an assessment of costs and benefits.
Costs:
* Yet another dependency, albeit optional
* Running the indenter (not sure it's noticable, but numbers wanted)
Benefits:
* Result is maybe tidier (examples wanted)
* Not in this patch: we could dumb down the code generator some (the
dependency becomes de facto mandatory for serious QAPI developers
then)
We may choose to shelve this patch until the next time decent formatting
takes us effort.
