[MPlayer-dev-eng] Offer of help to get me started

[D Richard Felker III]

On Mon, Mar 24, 2003 at 03:34:15AM +0100, Michael Niedermayer wrote:
> > I became noticeably faster at editing the HTML docs after I had
> > completely and nicely reformatted them in one run.  No more
> > reformatting has happened since that day.
> >
> > Another point evil tries to make is code readability for beginners or
> > people new to MPlayer.  I think he has a point there that is a blind
> agree, some of the code is hard to read&understand IMHO, but iam not sure if 
> reformating alone would solve this ...

I don't think it would make much difference at all. A short tech doc
on the flow of execution between the demuxers, decoders, etc. would
probably be a lot more beneficial.

> anyway, IMHO, some coding style recommanditions would be a good idea, 
> something like:
> * indention should be 4 or more spaces

I like this too but see no reason to require or recommend it.

> * meaningfull variable/function names (example:palette instead of plane[1])
> * cryptic code should be avoided, or at least well documented
> * #defines should be used instead of putting various constants in the code 
> without comments

These are a different type of "style"; we were mostly talking about
layout/formatting.

> * dont mix styles in a single file

Depends on what you mean by style...

> * avoid wrong indention like
> int main(int argc,char* argv[]){
> static demux_stream_t *d_audio=NULL;
> [... no {()}]
>         dvb_prev_next.prev = dvb_prev_next.next = -1;
> 	dvb_history = &dvb_prev_next;
> [... no {()}]
>   srand((int) time(NULL));

At the risk of annoying Michael, I'd like to also add:

* No javaStyle variableNames which lookHorrible to cCoders. :)

> but iam slightly against strict rules which force everyone to put the {} on a 
> specific line or enforce a indention width of 4 or 8 for everything

Definitely against that. Especially the location (or even presence) of
the {}. If having { sometime on the same line as the if and sometimes
on the next line seriously confuses you, you should NOT be coding. :)

> about the reformating/reindetion of existing code crusade, iam not sure if its 
> a good idea, it should at least be limited to the cases where it helps 
> readability

I think we could come up with a compromise where we just reformat a
few really ugly cases, and leave the rest of the code alone.
mplayer.c, mencoder.c, and probably lots of the demuxer stuff I've
never bothered to read (although that will be rewritten anyway) come
to mind. I am largely opposed to any strict style requirements,
however.

I know lots of people, especially beginners, have found Arpi's way of
maintaining things painful and offensive, so I'd just like to take a
minute to clarify my position on this. Before working with MPlayer, my
attitude towards having sources in CVS with lots of people all working
on the same code was that it was misguided and futile. The only
successful projects like this I'd seen were ones that were very
modular, where individuals could work on their own little piece
without impacting other people's work -- IIRC gimp was one like this,
but I may be mistaken. But most of the stuff I saw in CVS was broken,
incomplete, barely-started projects that some kid put on sourceforge
to get other people to finish his program for him. And so I wasn't too
excited about CVS and collective development models.

Then comes MPlayer. Somehow with a combination of chewing people out
over bad/crappy/nonsense/unnecessary changes, but allowing a huge
degree of flexibility of style to individual maintainers for parts of
the codebase, Arpi managed to make it all work *really well*. MPlayer
was much more featureful and less buggy than anything else out there.
If Arpi is really leaving his position as maintainer, we can't force
him to stay, but I think it would be very foolish to throw out all the
principles that made MPlayer development work so well without having
*very* well-thought-out reasons for why they absolutely need to be
changed, and without a consensus among active developers (which means
people writing code, as opposed to docs :).

Evil has brought up the analogy of Linux several times, but I don't
think that really applies. There's a huge difference in using a
unified style when there's a single maintainer who merges all the
patches, versus everyone committing their own changes. Also, it's
hardly a secret that porting patches to a slightly different version
of Linux is painful, and I imagine (though I admit I have done no
research on this issue) that silly stylistic changes are partly
responsible for the situation.

Oh well, that's it for now.

BTW, what happened to MPCF??? Is selecting a name the only thing left?

Rich