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

[Michael Niedermayer]

Hi

On Monday 24 March 2003 02:54, Diego Biurrun wrote:
> Anders Rune Jensen writes:
>  > 2) people can write code in _their_ style and when someone else wants
>  >    to read it he just pretty prints the way _he_ wants it to look.
>
> Most people here seem to agree that he who writes the code gets to
> impose his style preferences.  But evil (change that horrible name,
> son) is trying to make a point that is consistently being ignored:
>
> What about _files_ that do not have a consistent style?
>
> It's one thing to have a consistent style for the project or a
> consistent style for every file.
IMHO, the style within a file should be consistent ...

>
> 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 ...

anyway, IMHO, some coding style recommanditions would be a good idea, 
something like:
* indention should be 4 or more spaces
* 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
* dont mix styles in a single file
* 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));


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

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

[...]

Michael