[MPlayer-dev-eng] [PATCH] view stereoscopic videos

Uoti Urpala uoti.urpala at pp1.inet.fi
Fri Jan 29 13:17:03 CET 2010

On Fri, 2010-01-29 at 10:49 +0100, Gordon Schmidt wrote:
> This K&R style seems everything but logical to me. Why do i have to  
> put the { on the next line for function declarations, but not for  
> control statements?

This makes function definitions (declarations do not have braces) more
visually distinct. Also one extra line for the brace per function
definition is OK, but adding an extra line per each control statement
would add a lot of extra lines to some code.

>  Why do i have to put a whitespace before the  
> condition of an control statement but not before the params of a  
> function call?

Because they're completely different things?

>  And do i put a whitespace before the params of a  
> function declaration or not?

No (assuming that by "params" you again mean the opening parenthesis of
the parameter list).

>  I've found different rules via google all  
> claiming to be K&R. And why shouldn't i indent cases in a switch? They  
> are certainly part of the switch and should be indented like any other  
> content that's written between a block of { and }.

Arguably they're on the same logical level as the "switch" statement
itself even though they're inside the block. And this is a practical way
to make the case labels stand out. Using the same indentation level as
the code inside the block would make them much harder to spot, while
using one extra indentation level for the labels and two for the code
would add excessive amounts on indentation.

> I'm not sure, if i miss the point here, but aren't coding style rules  
> supposed to ease the writing and reading of the code? I don't think  
> they do, if the have different rules for statements with similar  
> structure like K&R seems to have.

I think you're using a weird definition of "similar structure".

> Maybe i'm just using the wrong documentations. In this case you should  
> provide a binding set of rules within the repository and i will change  
> the style on the next time i have to change something in the source.

The style produced by the "indent" program with the "-kr" switch should
be an OK reference. Note however that its output usually has some
problem cases that need to be corrected by hand.

> Btw: How big is the part of the mplayer source that complies to this  
> K&R rules anyway?

Old parts of MPlayer source are not a good example of anything, they
contain a lot of crap.

More information about the MPlayer-dev-eng mailing list