[FFmpeg-cvslog] r19695 - trunk/libavcodec/twinvq.c

[Aurelien Jacobs]

On Fri, Aug 28, 2009 at 01:11:53PM +0200, Michael Niedermayer wrote:
> On Tue, Aug 25, 2009 at 10:50:50AM +0200, Diego Biurrun wrote:
> > On Tue, Aug 25, 2009 at 04:16:37AM +0200, Vitor Sessak wrote:
> > > Diego Biurrun wrote:
> [...]
> > > >>--- trunk/libavcodec/twinvq.c	Mon Aug 24 15:43:33 2009 (r19694)
> > > >>+++ trunk/libavcodec/twinvq.c	Mon Aug 24 19:35:47 2009 (r19695)
> > > >>@@ -458,7 +458,7 @@ static void add_peak(int period, int wid
> > > >> 
> > > >>-    for (j=-width/2; j < (width+1)/2 && shape < shape_end; j++)
> > > >>+    for (j=-width/2; j < (width + 1)/2 && shape < shape_end; j++)
> > > >
> > > >There are still some operators on this line that could benefit from
> > > >whitespace, especially / and =.
> > > 
> > > I try to stick to K&R for most of the things but it goes a little too 
> > > far on extra whitespaces for my taste. I particularly hate doing
> > > 
> > > for (i = 0; i < 10; i++)
> > > 
> > > instead of
> > > 
> > > for (i=0; i < 10; i++)
> > 
> > That's the good thing about common styles: Nobody gets to be the
> > privileged person whose style gets picked.  Everybody has to adapt.
> 
> There is nothing good on "Everybody has to adapt"
> If it where we could go the full way to gnu style, for that people would
> have to adapt alot more and fight their better judgement also alot more.
> 
> 
> > Rest assured that there are parts of K&R I dislike as well.  But it's no
> > use complaining.  After a while you adapt and don't consider it
> > obnoxious anymore.  Tastes *are* malleable.
> 
> But dislike is an indication that there are problems, and
> i claim ommiting the spaces around * / is more readable. Also in
> mathematics with pencil and paper there are no spaces around * and / and
> actually * is not written at all its 
> A = 4ab + cd
> not 
> A = 4 * a * b + c * d
> And i think there is little question which is more readable and convenient
> 4ab is a more "strongly" bound unit than 4ab + cd so it makes sense to also
> use spaces differently
> 
> also as vitor is the author and maintainer of the file, the final decission
> is his on how to format it. I surely do prefer K&R like but not to the point
> of nitpickerish fineprint hunting like this

I absolutely agree with all of this !
The current level of nitpicking is often hurting code readability. And
systematic spaces around (most) operators is a good example of it.
I also agree with Vitor's feeling about spaces inside for().
Overall, I like having a common baseline (namely K&R) but I disagree about
blindly following the output of the indent software.

Aurel