> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Devin
> Heitmueller
> Sent: Freitag, 28. Februar 2025 01:40
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] doc/developer: Better {} style rule
>
> On Thu, Feb 27, 2025 at 5:57 PM James Almer <jamr...@gmail.com> wrote:
> > > would loooove a format defining script with a prehook that formats
> your
> > > patches before sending <3
> >
> > That can be done automatically as one of the many jobs CI runs once we
> > move to forgejo/gitlab. Same with every other check in patcheck.
>
> In my opinion, developers generally want to clean up style issues
> prior to submission. The problem with doing it in a CI job is that it
> will just tell you after the fact that your patch didn't meet the
> coding standards and you have to revise and resubmit. The alternative
> is for the CI job to "fix" the patch to conform, which people
> generally don't want because what they submitted is different than
> what gets committed.
>
> For what it's worth, with the Linux Kernel we solved this years ago
> with a "checkpatch.pl" which developers can run prior to committing.
> Thus I could quickly run checkpatch.pl, fix anything it complains
> about, and then run git commit and be confident that it conforms to
> the standard. Personally I prefer this approach as it lets me fix the
> patches prior to submission, and the CI system isn't changing things
> without my knowledge.
>
> That said, I'm not necessarily against a CI job which validates it
> meets the coding standards and kicks it back, to catch cases where the
> developer failed to run checkpatch prior to submission. This approach
> only really works well though if the developer had an automated means
> to run the check his/herself prior to submission.
Hi Devin,
I see it the same like you do, but even a bit more extreme: For me it must
happen while writing. I don't leave anything improperly formatted excepting the
current spot. Deferring formatting just causes trouble all the way in
combination with version control. I don’t know how others are working, but I'm
often making small commits which are pieced together later or commits with
something that needs to go into a previous commit. Or sometimes commits need to
be split and combined in a different way. When you are doing this this with a
"format later" or "format sometimes only" approach, a mix of
formatted/unformatted code lines will bite you all the time when
rebasing/merging things around.
So, I prefer tooling that shows warnings and assists in formatting while
typing.
I have a manually adjusted profile, but it's just an approximate solution - it
could be better.
What I had pitched a few years ago is the creation of a ruleset for a widely
supported linter like Clang-tidy or similar which resembles the ffmpeg coding
rules in detail. Then, everybody could use it in the way they prefer - be it
"live" in a full-featured IDE or just by running manually.
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
