[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Request for Comments: converting libcdio-paranoia C
From: |
Rocky Bernstein |
Subject: |
Re: [Libcdio-devel] Request for Comments: converting libcdio-paranoia C style - which "standard" to use? |
Date: |
Mon, 27 May 2024 12:48:56 -0400 |
Libcdio paranoia has been updated as a one-shot conversion to more-closely
match LLVM C code style. See
https://github.com/rocky/libcdio-paranoia/pull/44 for the changes.
If you have comments or concerns, let me know.
On Fri, May 17, 2024 at 1:01 PM Rocky Bernstein <rocky@gnu.org> wrote:
> Sorry for the delayed reply.
>
> Basically I guess I'll use the LLVM C code style since no one has a
> preference and that style seems detailed and specific enough. And the
> formatter is by the same folks, so conformance is probably pretty good.
>
> I plan on doing this as a one shot and only on libcdio paranoia which is
> pretty small. It can live in a branch for a little while too.
>
> I don't see any forced dependencies. While in Python projects there are
> commit hooks that do the formatting, here I don't plan on anything.
> Initially it can be done as a one-shot with no strong requirement of it
> hampering development.
>
> On Mon, May 13, 2024 at 3:47 PM <karl@aspodata.se> wrote:
>
>> Rocky Bernstein:
>> ...
>> > For example:
>> >
>> > for(;endA<sizeA && endB<sizeB;endA++,endB++)
>> > > if(buffA[endA]!=buffB[endB])break;
>>
>> Perfectly readable though a little cramped.
>>
>> [ about clang-format etc. ]
>> > First, any thoughts or comments on this? Any thoughts on which of the
>> many
>> > C "standard" styles to use? (The great thing about Standards is that
>> there
>> > are so many to choose from!)
>> ...
>>
>> Not that I have any say in this...
>> It is fine to define a coding style for check-in time, but don't force
>> people to work in that format. Just provide an indent- or clang-format
>> formula to be used before check-in time. Specify it and be done.
>> Do not require any extra dependancies just for the style.
>>
>
> As I mentioned above, initially I'll do this as a one-shot thing. I think
> it cool to add a mechanism for *optional * commit hook (in python
> pre-commit does this), I will leave that for others to do if there is a
> desre.
>
>
>
>>
>> Regards,
>> /Karl Hammar
>>
>>
>>