[MPlayer-dev-eng] Offer of help to get me started
kosh
evil_kosh_uk at yahoo.co.uk
Mon Mar 24 20:12:22 CET 2003
> If someone is so new to C that spacing prevents them from reading
> code, they'll introduce more bugs than they're worth...
It's not about preventing people from reading the code, it's about
putting an artificial barrier in front of people who might want to help,
but dont want to wade through badly formatted code which is hard to
comprehend without a lot of aspirin.
> > 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.
Well I thought an analogy would help you understand what I was trying to
say. I dont think analogies are bad. I think throwing abusive
statements at people you dont know say more about the person doing the
throwing, than the person doing the recieving.
> > > 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!!
Then you shouldnt really have any problem with seeing the entire
codebase in that similar style, should you? Also the linux kernels
style, used by linus too, is because he bent a little and wasnt so hard
nosed about his style that he couldnt compromise with people for the
better good of the project.
> > 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.
Again, with the insults. However, since you dont know me, I find it
hard how you can make such a statement. I have been writing C code,
along with C++ code for around 7 years.
> 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.
Then I guess I should inform you of your error.
> 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.
I made the offer because it's the first thing that came to mind, the
total uncoordination made me think that offering to clean it up would
help you and help anyone in my position.
> 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.
It's not a nonsense arguement, it's 100% correct, comprehension IS
affected by badly formatting code, anyone who says otherwise is either
ignorant or stupid. Of course, spending time to decode the code into
something that makes sense takes time therefore affecting how much code
you can comprehend at any one time. Jees, this isnt rocket science.
(I'm not making any friends with that statement, but right now, I'm
thinking I dont care that much)
There are statements in the code which indent CANNOT fix, let me give
you an example, case statements.
case something:{
}break;
case something:{
break;
}
indent going to fix that is it? no, I didnt think so.
> > 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.
You think that badly formatted code has no affect on the ability for a
new person to come along and start helping? Sorry, but thats stupidity
talking. If the code is hard to read and therefore hard to comprehend.
It will take longer for ANYONE to start contributing. I dont care who
you are, it's got nothing to do with your coding ability, but everything
to do with mental comprehension. Which is the same regardless of how
good a coder you are.
> > > 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.
I'm not doing this to help "you" exactly, I'm doing this, or proposing
this, in order to help others who want to help out, but can't or wont,
because the code is a mess.
> > 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?
See what I said above about indent and you'll no doubt understand that I
have tried it already
> > 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.
I dont think it's dumb, I think it's sad that you resort to insults in
what was a perfectly resonable conversation, but I am starting to think
this is why MPlayerXP started.
--
kosh <evil_kosh_uk at yahoo.co.uk>
More information about the MPlayer-dev-eng
mailing list