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

[Michael Niedermayer]

Hi

On Monday 24 March 2003 06:00, D Richard Felker III wrote:
> 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.
agree, and some docs about each demuxer
1. doc about the format (mainly if there is no doc about it/it was reverse 
engeneeered)
2. doc about how the specific demuxer works
for example i spended some time looking at demux_real.c and still dont 
completly understand it

btw, if someone wants to do 1. then he might perhaps want to ask mike melanson 
about help, as he seems to be very interrested in helping, he did actually 
help me alot in writing the msmpeg4 format doc (spellchecking, noticng 
unclear parts, ...) 

[...]
> > * 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"; 
yes, its a short style recommandition list thingy ...

> we were mostly talking about layout/formatting.
yes

>
> > * dont mix styles in a single file
>
> Depends on what you mean by style...
for(i=0; i<l; i++){
	i=i+1;
}
vs.
for(i=0; i<l; i++){
 i=i+1;
}

IMHO, adding a if(){...} around a large part of code should be an allowed 
exception

>
> > * 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. :)
ok, but only if we add to the style guide
* No c_style variable_names which look_horrible to every_one :)
what 4B0Ut EL13t3 sT1L3_Ph4Ri4bl3 N4M3Z? ;)

[...]
> > 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
agree, IMHO mplayer/mencoder.c + demuxers would benefit from some reformating 
...

[...]
> BTW, what happened to MPCF??? Is selecting a name the only thing left?
chapters, playlists, ... are still missing/incomplete, but they can be added 
later ...

[...]

Michael