[FFmpeg-soc] [soc]: r3884 - amr/amrnbdec.c

[Michael Niedermayer]

On Mon, Dec 15, 2008 at 02:03:03PM +0000, Robert Swain wrote:
> 2008/12/15 Diego Biurrun <diego at biurrun.de>:
> > On Mon, Dec 15, 2008 at 01:13:11PM +0100, Benjamin Larsson wrote:
> >> Robert Swain wrote:
> >> > 2008/12/15 Robert Swain <robert.swain at gmail.com>:
> >> >
> >> >> 2008/12/15 diego <subversion at mplayerhq.hu>:
> >> >>
> >> >>> Log:
> >> >>> K&R function declaration and whitespace cosmetics
> >> >>>
> >> >>> --- amr/amrnbdec.c      (original)
> >> >>> +++ amr/amrnbdec.c      Mon Dec 15 11:13:50 2008
> >> >>> @@ -126,8 +126,9 @@ static int amrnb_decode_init(AVCodecCont
> >> >>>
> >> >>> -enum Mode decode_bitstream(AVCodecContext *avctx, uint8_t *buf, int buf_size, enum Mode *speech_mode) {
> >> >>> -
> >> >>> +enum Mode decode_bitstream(AVCodecContext *avctx, uint8_t *buf, int buf_size,
> >> >>> +                           enum Mode *speech_mode)
> >> >>> +{
> >> >>>
> >> >> Urgh. I'm happy with the line breaks but I don't tend to like the
> >> >> opening { on a new line. I thought that was a GNU thing not a K&R
> >> >> thing.
> >> >
> >> > Nope, it is K&R. Hmm, then who likes them on the same line other than me? :)
> >>
> >> I do, it is more readable to me. More code per loc.
> >
> > With that kind of reasoning, we can also prefer
> >
> >    if (condition) statement;
> >
> > over
> >
> >    if (condition)
> >        statement
> >
> > and similar.
> >
> > But this discussion is completely pointless IMO.  The rules have been
> > set in http://ffmpeg.org/general.html#SEC24:
> >
> >  Indent size is 4. The presentation is the one specified by 'indent -i4
> >  -kr -nut'. The TAB character is forbidden outside of Makefiles as is any
> >  form of trailing whitespace.
> >
> > Now it's clear that each person will dislike some part of K&R style and
> > prefer to do things in other ways.  But the nature of compromises is
> > exactly that: You accept a few things you may not be terribly fond of
> > and you get a uniform style in exchange.
> 
> Mmm. There are a fair few instances of { being on the same line as the
> function declaration so I guess you'll have to do those too. I still
> don't like it but it is personal preference and if that's what's been
> agreed, I won't argue about something like this.
> 
> If it hadn't been agreed project-wide, I would have preferred to have
> been consulted about the changes before they were committed
> considering it's my code. Even if I haven't touched it for a while, I
> am still active.

i dont remember { placement for functions being discussed or agreed upon.
and i prefer them on the same line as well. Though i am not strongly
opposed to following K&R, just that if most people prefer them like we
do, that following K&R just because of it would be silly.
Also i think that code should not be reformatted against the maintainers
wishes.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/ffmpeg-soc/attachments/20081215/bbe941f5/attachment.pgp>