[MPlayer-cvslog] r19188 - trunk/mplayer.c
Diego Biurrun
diego at biurrun.de
Tue Aug 15 11:41:50 CEST 2006
On Sun, Aug 13, 2006 at 03:08:27PM +0200, Roberto Togni wrote:
> On Sun, 13 Aug 2006 11:12:04 +0200
> Diego Biurrun <diego at biurrun.de> wrote:
>
> > So given that three active developers agree that such a thing is
> > desirable, is it time to discuss some sort of style guidelines?
>
> I'm against it, unless you can enable it on single files: but probably
> even in this case you'll have to allow every developer to enforce his
> own style, and have a list where the requirements for every guarded
> file are clearly stated.
> And that will prevent to use the script on common files that have no
> mantainer and are usually changed by more than one developer.
.. unless there is a way to settle on a common style ..
> - MPlayer does not enforce a formatting style, so you can't easily
> create a script to check it. The only rule is "try to follow the style
> of the surrounding code", if you create something new you can use the
> style you prefer.
> - some devels want to use tabs in their files (check archives)
> - some files are indented with 2 spaces, some with 4, others with
> tabs. Some have variable indentation because some code was added at an
> intermediate level to avoid cosmetic changes
.. which results in a mess ..
> - pre commit scripts are imo very annoying, especially if they don't
> point out exactly what is wrong and where the problem is; that's even
> worse when you are committing patches from other people.
pre-commit scripts are made to catch mistakes of the type that humans
can easily overlook, but are easy to check mechanically. So yes, they
can be annoying. That's their job. Probably there is still room for
improvement in the scripts. Then again, if you have trouble with tabs
and trailing whitespace, maybe you should consider an editor that takes
care of these things automatically...
> But there's a thing that worries me, not related only to this specific
> subject: MPlayer was developed for years with few, simple rules; why
> now we have the need to regulate every single detail of development?
>
> What's the problem with MPlayer development? Why now we need hard
> written rules for everything, else every single commit ends up in a
> flamewar?
We've always had many rules, but not that many were explicitly written
down. And I don't think there were less flames years ago, you just seem
to be forgetting the good old times ;)
Diego
More information about the MPlayer-cvslog
mailing list