[MPlayer-cvslog] r24941 - trunk/mplayer.c

Michael Niedermayer michaelni at gmx.at
Sun Nov 4 17:45:26 CET 2007


On Sun, Nov 04, 2007 at 05:37:59PM +0200, Uoti Urpala wrote:
> On Sun, 2007-11-04 at 10:13 +0100, Nico Sabbi wrote:
> > You are the only one that doesn't make the slighest effort to
> > prevent breaking gcc 2.95, even when it would cost nothing 
> 
> It would cost in code quality. 

thats your oppinion, and i for one at least disagree, and while i dont
know it, i think others disagree as well


> For example in this case the variable
> declaration is irrelevant clutter at the start of the function, while
> the type of the variable is obscured in the part of code where it is
> used. 

having variable declarations together helps seeing well all the variables
this is certainly usefull for optimizations, as the reader will immedeatly
spot functions which use many variables and might then try to change the
code to use fewer. thus making it easier for the compiler to generate
fast code


> I'm also not willing to make a habit of writing inferior code.

i think the correct way to phrase it would be
"iam the law, only my oppinion counts, and i consider that what the majority
thinks is best, inferrior. And i give a damn about what the other devels
think"

i really would love to see 2 or 3 uotis to have mplayer svn write access
it would nicely show how absurd and unpractical this view is in a larger
group
having one who knows better works as long as everyone else doesnt mind
being treated like shit, having 2 such guys and watching them argue with
each other how each of their ways is ultimately supperior would be really
entertaining
uoti, you dont happen to have a brother? do you?


> 
> I learned C before C99 existed, and later made a conscious effort to
> update my coding style to use C99 features. That's something I think
> more people should do - not limited to C features but to development
> practices in general. I learned that using features such as free
> variable declaration placement do allow me to write better code. That's
> the kind of code I want to create and practice writing.

well, i also leared C before C99 existed but being a unlucky guy i happened
to learn it while my primary machine was still running window$ and the "C"
compilers there allowed free ordering of declarations and statements

over time i realized that there are extreemly few cases where the random
placement of statements and declarations help code clarity
besides that, my first patch i submitted to mplayer also containd such
mixed statements and declarations, arpi politely asked me to remove these
and i did, it didnt worsen code readability and only took a few minutes time

but the part you completely ignore is that if you contribute to a project
you have to follow the rules that project has and noone who works on the
project will agree with every rule, if now everyone ignores the rules
then quickly things will turn into a mess
you would drop gcc 2.95, 3.* support (due to your mixing of declarations and
statements as well as the asm sytax you use)
now maybe i dont like gcc 4+ and would commit code which breaks it, hey
why not gcc 2.95 IS supperior
a few other people would think that macosx and win32 support are against their
free OSS philosophy and would thus break them
next someone would remove all asm because that is not clean, high level
code is always better and its the compiler job to optimize code
then 2 developers would start a commit war about reindenting the code
for 4 or 8 space indention
...

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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-cvslog/attachments/20071104/52460111/attachment.pgp>


More information about the MPlayer-cvslog mailing list