[MPlayer-dev-eng] the great reformatting

[Rudolf Polzer]

On Wed, Feb 16, 2011 at 08:21:58AM +0100, Ingo Brückl wrote:
> Dan Oscarsson wrote on Tue, 15 Feb 2011 18:32:43 +0100:
> 
> > Adding space on each side of an mathematical operator is not always
> > better.
> 
> > I think it is easier to read if type conversion is next to the data
> > being converted to show what is being converted.
> 
> I disagree. Like in orthography spaces make it easier for humans to
> comprehend the content. But just as there are languages with orthography
> where there is no spacing there are different preferences concerning spaces
> in programming languages.

Especially for mathematical operators, spacing can be used to make a formula
more readable.

E.g. compare:

1.
foo = a*b+c*d;
bar = (a+b)*(c+d);

2.
foo = a*b + c*d;
bar = (a+b) * (c+d);

3.
foo = a * b + c * d;
bar = (a + b) * (c + d);

4.
foo = a * b + c * d;
bar = ( a + b ) * ( c + d );

Here, I prefer 2. over 3., and that over 4., which I prefer over 1. However, an
automated indent tool typically won't be able to generate style 2, as it is not
well defined which spacing to use. For example, in this style it may be
arguable whether

baz = (a+b)*c + d

or

baz = (a+b) * c + d

is "correct".

Regarding casts... generally, I would prefer

(int)value

but

(unsigned int)value

looks kind of weird as it has a space inside the parentheses, yet still the
parentheses "stuck" to the value. Of course, the obvious fix is e.g. a typedef:

(uint)value

With the typically long C type names, however, I tend to prefer putting a space
after the cast, BUT also parentheses around the whole cast expression:

((unsigned int) value)

But, all this is just personal opinion.

Best regards,

Rudolf Polzer