2008/12/15 Diego Biurrun <di...@biurrun.de>:
> On Mon, Dec 15, 2008 at 01:13:11PM +0100, Benjamin Larsson wrote:
>> Robert Swain wrote:
>> > 2008/12/15 Robert Swain <robert.sw...@gmail.com>:
>> >
>> >> 2008/12/15 diego <subvers...@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.
Regards,
Rob
_______________________________________________
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
