Re: [FFmpeg-devel] [PATCH] doc/developer: Better {} style rule

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@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 <jamrial@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-request@ffmpeg.org with subject "unsubscribe".