libcdio-devel
[Top][All Lists]
Advanced

[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
>>
>>
>>


reply via email to

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