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

[D Richard Felker III]

On Mon, Mar 24, 2003 at 01:21:08AM +0000, Evil Kosh wrote:
> > > source and found that people were using spaces here, tabs there,
> > > sometimes the brace would be after the if/switch/for statement on the
> > > same line, others would have it below, others wouldnt have one at all.
> > 
> > And all are perfectly readable if you're remotely competent with C.
> 
> yes, it's readable, but mostly by the people who wrote it.  If you are
> new to the codebase, it just looks like (in some places) a big jumble of
> code which has no "style".  Even a newbie at C understands that a big
> source code base can become harder to maintain and attract newcomers who
> may be able to help, when the code is written by certain people, for

If someone is so new to C that spacing prevents them from reading
code, they'll introduce more bugs than they're worth...

> I suppose what I'm essentially saying here, is that everyone can read
> the alphabet, but it only becomes legible or useful, when those letters
> are put together in a structured, well understood manner.  a jumble of
> letters according to each developer how they like it, is harder to
> read.  Even if the end decoded product makes sense to people.

Please stop trying to argue by analogy. This is a classic fallacy and
almost always makes one look like a fool, especially when the analogy
is bad like here.

> > That's nice. I agree totally with Linux's style and use it myself, but
> > I disagree totally with trying to reformat everyone's code to meet
> > some arbitrary standard like that.
> 
> well this is what I find hard to understand.  You agree with linux's
> style, yet you dont think it's right that the code should undergo a
> reformat to meet an agreed style.  At one point, the linux code
> underwent this change too and like you said, you totally agreed with

No. By agree I mean I find the style visually pleasing and use it
myself almost exactly. Nothing to do with imposing it on anyone.

BTW, lots of Linux is *not* in Linus's coding style!!

> as for the professional part of what I said.  I'm more talking about
> coding in a professional frame of mind, as opposed to coding in a
> professional manner.  What I mean by that is that you, for the good of
> the dev team, agree on a style by which everyone understands and
> implements.  You eliminate the aspect of reading the code whereby you
> have to decode the style first, then only can you understand the code. 
> Of course any competent C coder can do this, but why should they? just
> to be leet?

I don't have to decode any of it because I'm competent at reading C.
Apparently you are not.

The general impression I get is that you're a CS student who's never
written a real program and just took a "Software Engineering" course,
and decided to go try to apply all that dogmatic nonsense to someone
else's project.

Even if you ideas were good, it is socially inept of you to barge into
the list totally unknown and tell everyone you want to make a sweeping
change like this that is explicitly forbidden in the documentation
(DOCS/tech/patches.txt). At the very least you should already be a
respected contributor who's proved his worth through useful code
before proposing that we bend over backwards to do things you way.

Anyway, what sort of improvements to you actually plan to work on?
MPlayer is rather modular these days, so if you just want to write new
a/v filters or drivers, subtitle loaders, demuxers, etc. then you
*don't* need to understand the core that you were trying to reformat
whatsoever. If you actually plan to make large rewrites to the core to
address some of its problems (which I doubt, since I seems you have
not read the list in the past, so you probably don't even know what
its problems are), then proposing a reformat of the relevant files
would be reasonable, but still a topic open to debate.

> i dont think it costs flexibility at all.  If by what you mean it tells
> people to code in a certain way, instead of any old fashion then yeah, I
> guess it does.  But when projects get bigger and bigger, you have to
> lose flexibility in a tradeoff with comprehension.

No. Quit this nonsense argument. Comprehension is not affected by
spacing since you can change it any-which-way you like with the indent
program in your local copy.

> I may misunderstand this, how much more complicated can it get?  It's
> not complicated at all to me.  There are 10+ people developing mplayer

Suppose I add a conditional around a 100-line block of code. If I
re-indent that whole block when I commit the new conditional, the cvs
log is totally unreadable and no one can see that only one small
"if (blah) {" and "}" were actually added.

> all using different styles to code and the code as a result is hard to
> read.  I'm offering to solve that and all it takes is for people to put
> away their hacker spirit for a second and talk about it.  I know people
> here must be reading this thinking "oh man, you mean I have to change my
> style, f**k that".  But as competent C coders you are all capable of
> logical, reasoned thought.  A single style for the whole mplayer
> codebase would make the code easier to read for new people and eliminate
> a entire decode layer in comprehending the code.  How can that be a bad
> thing?

No. Becoming familiar with the code *is* difficult (believe me, it
took me a long time!!) but it had nothing to do with indention and
layout. There are other stylistic matters that *can* affect
comprehension (variable and function naming, reliance on lots of
external/global variables, etc.), but that's another matter entirely.

> > If you want to *help* with the project, then write useful code that
> > does something. Reformatting to try to 'beautify' the source is not
> > coding, it's just a huge waste of time. Like Arpi has said, there are
> > programs that can do that for you. If you are simply unable to read
> > the source as it is (most likely this means you have a broken text
> > editor with tabwidth!=8), then reformat your local copy with the
> > indent program while working on it.
> 
> reformatting the code is what I think the source needs.  I'd like to

Well then you're not what we need.

What MPlayer needs is people to:

o Fix bugs
o Reverse engineer and implement codecs and demuxers
o Fix dvd-nav support (I don't like it but lots of users want it)
o Optimize even more for speed :))
o Write more audio and video filters
o Rev eng and write drivers for more video cards
o Etc...?

If all you can do is act as a slow human computer that runs the
"indent" program on your wetware (i.e. brain), I don't see how you're
helping us.

> therefore ask people to think about it and when I post my updated
> mplayer.c you can judge for yourself.  you may see this as a waste of
> time, but whose time is being wasted? mine.  I think it needs doing,
> it's my time, let me waste it.  Please dont disagree with me on this
> just to stop me wasting my time.

And you're wasting my time because I feel a need to explain to the
list why your ideas are bad, so that the ignorant don't simply think
"hey cool, let's do that!" and go along with you.

> Arpi is right, there are programs which can reformat code, but you
> usually have to do it on new incoming code and they dont tend to work
> well with massive codebases like mplayer.  There are parts of the
> codebase which I dont think automated programs like indent would be able
> to reformat.  

Then why don't you try it and see?

> What should have happened is that mplayer should have had a style guide
> from the beginning really.  Arpi obviously didnt think of it because it

That's your opinion.

> was only him doing the work, but as everyone can now see, as the
> codebase has grown enormously, a style is starting to become needed
> (just like what happened with the linux kernel, when it started to

Linux is a kernel, so stop saying "the linux kernel". It sounds really
dumb.

> attract more people, all coding in _their_ style, they had to form a
> style guide to keep people in check and to stop people from polluting a
> good source base with badly formatted, illegible code, not that I'm
> saying mplayer has any).  Perhaps you dont see it because you've worked
> with the code for so long, but from my point of view, the code is hard

I haven't. For the most part I've only written a few video filters and
worked on mencoder.c (which is a huge "mess" in terms of indention
style, but that doesn't make it hard to read, just "ugly").

> to read, understand and break into.  I want to correct that and you have
> everything to gain and only a small amount of your personal coding style
> will be sacrificed.  It's not a big price to pay, but I think it would
> help and I'm offering it.

None will be sacrificed because it's not going in.

BTW, where's Gabu when we need him? :))

Rich