[Ffmpeg-devel] [PATCH] indentation cosmetics

Michel Bardiaux mbardiaux
Mon Sep 4 14:46:12 CEST 2006


Rich Felker wrote:
> On Wed, Aug 30, 2006 at 02:03:24PM +0200, Michel Bardiaux wrote:
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Wed, Aug 30, 2006 at 12:16:44PM +0200, Michel Bardiaux wrote:
>>>> Michael Niedermayer wrote:
>>>>> Hi
>>>>>
>>>>> On Wed, Aug 30, 2006 at 10:35:19AM +0200, Michel Bardiaux wrote:
>>>>>> Changes made by emacs 21.4.1 with settings:
>>>>>>
>>>>>> c-set-style cc-mode
>>>>>> set-variable indent-tabs-mode nil
>>>>> rejected of course
>>>>>
>>>>> [...]
>>>> I dont understand at all. I thought I understood the rules: no hard 
>>>> tabs, tabwidth 4, and my settings seemed to match that. What is the 
>>>> problem?
> 
> I don't see any document that says that the files must match the
> result of running gnu indent or emacs indention with those settings,

I never thought there was such a rule. I just considered that this emacs 
setting was a good way to ensure that my patches conformed to the rules 
that *do* exist (4 spaces, emulate tabs).

> just that tabs (however they're used) should consist of 4 spaces and
> not use the tab character... That is, ..
> 
>>> Index: libavformat/img2.c
>>> ===================================================================
>>> --- libavformat/img2.c	(revision 6126)
>>> +++ libavformat/img2.c	(working copy)
>>> @@ -106,7 +106,7 @@
>>>     for(first_index = 0; first_index < 5; first_index++) {
>>>         if (get_frame_filename(buf, sizeof(buf), path, first_index) < 0){
>>>             *pfirst_index =
>>> -            *plast_index = 1;
>>> +                *plast_index = 1;
>> It continues the previous statement (the *pfirst_index =) so it should 
>> be indented one level more than the statement it continues.
> 
> ... nothing is said about continued statements ...
> 
>>>             return 0;
>>>         }
>>>         if (url_exist(buf))
>>> @@ -142,7 +142,7 @@
>>>     *pfirst_index = first_index;
>>>     *plast_index = last_index;
>>>     return 0;
>>> - fail:
>>> +  fail:
>>>     return -1;
>>> }
>>>
>> Mmm, most of the fail: labels at function level seem indented by 1 
>> space, but there are exceptions:
> 
> ...or about indention or nonindention of labels...
> 
>> What's the rule? And is there some emacs setting that enforces all the 
>> rules?
> 
> I'm not a real ffmpeg developer but I would suggest the rule be
> "whatever is readable and looks good" within the above constraints. If
> you're going to specify spacing style so tightly that a machine can do
> the whitespace for you, then you might as well omit all whitespace in
> the file and let the machine format it for you at display-time....
> 
> Rich
> 
Plus apparently an extra rule: one should never change existing 
indentation if it respects the 2 rules (4, emulate tabs).

But that means I now have a choice of indenting by hand, or of checking 
every patch for changes that affect indentation only. What a waste of 
time. Does rule 3 (no change) apply even when there is *functionality* 
change in the line.

-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/




More information about the ffmpeg-devel mailing list