:: Hi Everyone,
::
:: I haven't been keeping up with things for the last week, because
:: my wife and I just had our first baby :-) (baby's requisite website:
:: www.wildpuppy.com/baby)
::
:: Anyway, now LAME CVS fails all my test cases. This is normal since
:: small changes in just the order of operations will show up in these
:: tests. I normally then track down exactly what is responsible and
:: make sure I understand what is going on. But in this case it looks like
:: this will not be possible: There are massive differences in every
:: single file. Most of them may be long overdue, but for the most part
:: they are related to coding style and/or cosmetic.
::
what CODING style?
Sorry, it is very laborious to only read (not understand) the source code.
Currently the first action in the editor is the auto-format features of xjed.
It only takes 1 or 2 seconds, but the code can't be checked in anymore.
Transmitting the changes from the local copy to the 'commit'-able
version is sinewy, especially line by line.
It begins with the simpliest things like tabulators '\t' with different
sizes (3, 4 and 8 are used in lame), continues with circle references in
header files (try to change the type of internal_flags from 'void*' to
'lame_internal_flags*') and ends with dangerous variable names like
gfc->stereo and incorrect code due to provoked misunderstandings. It uses
some features still tolerated by the ANSI C3.159-1989 standard and strictly
forbidden in C99 and C++.
A lot of things I've not seen for 3 or 4 years.
May be features should be stopped for 2 or 3 days and only these things
should be solved.
The simpliest way to get a coding style is to use
/usr/src/linux/Documentation/CodingStyle .
May be there are better coding styles (note that coding styles are
also a question of personal taste), but this coding style is the coding
style of one of the most successful projects and it is much better than
every tohuwabohu.
:: It is not approrpriate for new developers to make so many changes so
:: quickly without consulting the rest of us.
::
Waiting for more than 2 or 3 days makes it nearly impossible to check in
changes. That are the results of the usage of SourceSafe at work.
--
Mit freundlichen Gr��en
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
