[MPlayer-dev-eng] [bikeshed] Coding style

[Michael Niedermayer]

On Wed, Jun 18, 2008 at 09:51:13AM +0200, Nico Sabbi wrote:
> On Wednesday 18 June 2008 01:14:31 Michael Niedermayer wrote:
> > On Wed, Jun 18, 2008 at 12:58:03AM +0200, Luca Barbato wrote:
> > > Ivan Kalvachev wrote:
> > > > How about do the minimum.
> > > > Aka
> > > > remove all whitespaces from end of line,
> > > > replace all tabs with spaces
> > > > and do 4 space indent.
> > > >
> > > > Leave the rest as it is.
> > > >
> > > >
> > > > Doing this may not even break patches,
> > > > as there is option "-l" to ignore whitespace changes.
> > > > It should work as long as we don't move stuff up and down.
> > >
> > > That's a good start, I think we should try this one this weekend.
> >
> > agree
> >
> > [...]
> 
> I have to say that I really _hate_ space indentation (instead of tabs)

Why? I mean it doesnt really make a difference from a "users" point of view
you press tab either way in a correctly configured editor.


> and kr-style (unaligned braces) . 

I think ivans suggestion was to leave the braces where they are and just
reindent that is
for()
{
  dlskfslkdf;
sflkgjfsl;
        lfdigjofdjg;
}

would be chnaged to
for()
{
    dlskfslkdf;
    sflkgjfsl;
    lfdigjofdjg;
}

At least that was how i understood ivans suggestion


> I'm willing to capitolate at everything, but you please leave
> alone my vertically aligned braces?

I think we should find the greatest common denominator of what people can
live with and do that to all files not taken from external projects.

For the remainder we could very well have per file or per maintainer styles.
We still would achive what we want, that is a clean & readable mplayer source
while the problem of finding an agreed mplayer style would vanish.

Of course the more similar the per maintainer styles are, the easier for
everyone  ...
Having to reconfigure ones editor between tabs and spaces indention is
annoyng for example or switching tab width, so i hope we can agree on
either tabs or spaces and the indention width at least ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080618/fa7c99b3/attachment.pgp>