Comma at end of enum lists

Comma at end of enum lists

[Jacek Luczak]

Hi All,

I've found that in many enum lists, there's a comma at the end, e.g. 
(arch/x86/kernel/early_printk.c):

enum {
         MAGIC1 = 0xBACCD00A,
         MAGIC2 = 0xCA110000,
         XOPEN = 5,
         XWRITE = 4,
};

Just out of curiosity, is there any particular reason here (no word in 
CodingStyle about that).

-Jacek

Re: Comma at end of enum lists

[Mikael Pettersson]

Jacek Luczak writes:
 > Hi All,
 > 
 > I've found that in many enum lists, there's a comma at the end, e.g. 
 > (arch/x86/kernel/early_printk.c):
 > 
 > enum {
 >          MAGIC1 = 0xBACCD00A,
 >          MAGIC2 = 0xCA110000,
 >          XOPEN = 5,
 >          XWRITE = 4,
 > };
 > 
 > Just out of curiosity, is there any particular reason here (no word in 
 > CodingStyle about that).

Yes. This idiom allows you to add or remove items without
changing adjacent lines.

In a language with strict a comma-as-separator rule you can
get this benefit by placing the comma before new items rather
than after existing items:

enum {	FOO
	,FIE
	,FUM
};

but luckily C doesn't need this perversion.

Re: Comma at end of enum lists

[H. Peter Anvin]

Jacek Luczak wrote:
> Hi All,
> 
> I've found that in many enum lists, there's a comma at the end, e.g. 
> (arch/x86/kernel/early_printk.c):
> 
> enum {
>         MAGIC1 = 0xBACCD00A,
>         MAGIC2 = 0xCA110000,
>         XOPEN = 5,
>         XWRITE = 4,
> };
> 
> Just out of curiosity, is there any particular reason here (no word in 
> CodingStyle about that).
> 

Yes, it's so you can add a line without affecting the line before it, 
making a one-line patch into a two-line patch that's more likely to 
conflict.

	-hpa

Re: Comma at end of enum lists

[Jacek Luczak]

Mikael Pettersson pisze:
> Jacek Luczak writes:
>  > Hi All,
>  > 
>  > I've found that in many enum lists, there's a comma at the end, e.g. 
>  > (arch/x86/kernel/early_printk.c):
>  > 
>  > enum {
>  >          MAGIC1 = 0xBACCD00A,
>  >          MAGIC2 = 0xCA110000,
>  >          XOPEN = 5,
>  >          XWRITE = 4,
>  > };
>  > 
>  > Just out of curiosity, is there any particular reason here (no word in 
>  > CodingStyle about that).
> 
> Yes. This idiom allows you to add or remove items without
> changing adjacent lines.

Yep, that's obvious, one line less in diff after every enum change  :)

> In a language with strict a comma-as-separator rule you can
> get this benefit by placing the comma before new items rather
> than after existing items:
> 
> enum {	FOO
> 	,FIE
> 	,FUM
> };
> 
> but luckily C doesn't need this perversion.
> 

I was just curious, because it's not common schema (some miss extra comma).

Thanks,
	-Jacek

Re: Comma at end of enum lists

[Al Viro]

On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
> Jacek Luczak wrote:
> >Hi All,
> >
> >I've found that in many enum lists, there's a comma at the end, e.g. 
> >(arch/x86/kernel/early_printk.c):
> >
> >enum {
> >        MAGIC1 = 0xBACCD00A,
> >        MAGIC2 = 0xCA110000,
> >        XOPEN = 5,
> >        XWRITE = 4,
> >};
> >
> >Just out of curiosity, is there any particular reason here (no word in 
> >CodingStyle about that).
> >
> 
> Yes, it's so you can add a line without affecting the line before it, 
> making a one-line patch into a two-line patch that's more likely to 
> conflict.

Note that doing that makes sense only when you can expect additions to
the end and even then it's a matter of taste.

Re: Comma at end of enum lists

[Jacek Luczak]

Al Viro pisze:
> On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
>> Jacek Luczak wrote:
>>> Hi All,
>>>
>>> I've found that in many enum lists, there's a comma at the end, e.g. 
>>> (arch/x86/kernel/early_printk.c):
>>>
>>> enum {
>>>        MAGIC1 = 0xBACCD00A,
>>>        MAGIC2 = 0xCA110000,
>>>        XOPEN = 5,
>>>        XWRITE = 4,
>>> };
>>>
>>> Just out of curiosity, is there any particular reason here (no word in 
>>> CodingStyle about that).
>>>
>> Yes, it's so you can add a line without affecting the line before it, 
>> making a one-line patch into a two-line patch that's more likely to 
>> conflict.
> 
> Note that doing that makes sense only when you can expect additions to
> the end and even then it's a matter of taste.
> 

I think it's hard to ,,expect additions'' or just predict them. But 
smaller patch (diff) is one of things that makes sens of adding extra 
commas. I'm just pedantic here.

-Jacek

Re: Comma at end of enum lists

[H. Peter Anvin]

Al Viro wrote:
> On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
>> Jacek Luczak wrote:
>>> Hi All,
>>>
>>> I've found that in many enum lists, there's a comma at the end, e.g. 
>>> (arch/x86/kernel/early_printk.c):
>>>
>>> enum {
>>>        MAGIC1 = 0xBACCD00A,
>>>        MAGIC2 = 0xCA110000,
>>>        XOPEN = 5,
>>>        XWRITE = 4,
>>> };
>>>
>>> Just out of curiosity, is there any particular reason here (no word in 
>>> CodingStyle about that).
>>>
>> Yes, it's so you can add a line without affecting the line before it, 
>> making a one-line patch into a two-line patch that's more likely to 
>> conflict.
> 
> Note that doing that makes sense only when you can expect additions to
> the end and even then it's a matter of taste.

Yes, it is.

I personally prefer it this way (strongly) for exactly the same reason C 
requires a semicolon at the end of each statement, as opposed to Pascal 
which doesn't require a semicolon immediately before an "end".

	-hpa

Re: Comma at end of enum lists

[Jan Engelhardt]

On Saturday 2008-03-29 18:28, H. Peter Anvin wrote:
>>
>>  Note that doing that makes sense only when you can expect additions to
>>  the end and even then it's a matter of taste.
>
> Yes, it is.
>
> I personally prefer it this way (strongly) for exactly the same
> reason C requires a semicolon at the end of each statement, as
> opposed to Pascal which doesn't require a semicolon immediately
> before an "end".

...as opposed to Perl which does not strictly require a ; at the
end of a block. :>

# while (1) { print 1; print 2 }

Re: Comma at end of enum lists

[Al Viro]

On Sat, Mar 29, 2008 at 10:28:26AM -0700, H. Peter Anvin wrote:
> Yes, it is.
> 
> I personally prefer it this way (strongly) for exactly the same reason C 
> requires a semicolon at the end of each statement, as opposed to Pascal 
> which doesn't require a semicolon immediately before an "end".

enum foo {
	Foo,
	Bar,
	Baz,
	Max_foo = Baz
};

when you know there won't any additions past the last line (for that matter,
ending it with
	Baz,
	Sentry_foo,
	Max_foo = Sentry_foo - 1
}; is also an option, in which case the end of enum will never be touched
at all).

enum {Some_constant = ...};

when you do not want to mix it with other constants and use a separate
enum for each natural group.

Sometimes it makes sense, sometimes it doesn't.  It is an expressive
element, not something to be cast in stone by Documentation/CodingStyle.

Re: Comma at end of enum lists

[H. Peter Anvin]

Al Viro wrote:
> 
> when you know there won't any additions past the last line (for that matter,
> ending it with
> 	Baz,
> 	Sentry_foo,
> 	Max_foo = Sentry_foo - 1
> }; is also an option, in which case the end of enum will never be touched
> at all).
> 

Yes, that's a very important exception.  Don't put the comma in if you 
want the set to be actively closed.

	-hpa

Re: Comma at end of enum lists

[Al Viro]

On Sat, Mar 29, 2008 at 06:26:33PM +0100, Jacek Luczak wrote:

> I think it's hard to ,,expect additions'' or just predict them.

Depends on the situation.

> But 
> smaller patch (diff) is one of things that makes sens of adding extra 
> commas. I'm just pedantic here.

Fine, but please let's not turn that into yet another brainless crusade;
we already have enough of those going...

Re: Comma at end of enum lists

[H. Peter Anvin]

Al Viro wrote:
> Fine, but please let's not turn that into yet another brainless crusade;
> we already have enough of those going...

Amen!

	-hpa

Re: Comma at end of enum lists

[Andreas Schwab]

Mikael Pettersson <mikpe@it.uu.se> writes:

> In a language with strict a comma-as-separator rule you can
> get this benefit by placing the comma before new items rather
> than after existing items:
>
> enum {	FOO
> 	,FIE
> 	,FUM
> };
>
> but luckily C doesn't need this perversion.

Only since C99 (but GNU C never needed it either).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Comma at end of enum lists

[Jan Engelhardt]

On Saturday 2008-03-29 19:13, Andreas Schwab wrote:
>> In a language with strict a comma-as-separator rule you can
>> get this benefit by placing the comma before new items rather
>> than after existing items:
>>
>> enum {	FOO
>> 	,FIE
>> 	,FUM
>> };
>>
>> but luckily C doesn't need this perversion.
>
> Only since C99 (but GNU C never needed it either).

C had this for much longer than 99. Borland Turbo C from around 1990
(which you can expect to be C89 if you have luck) also allows , at the end.

Re: Comma at end of enum lists

[Andreas Schwab]

Jan Engelhardt <jengelh@computergmbh.de> writes:

> On Saturday 2008-03-29 19:13, Andreas Schwab wrote:
>>> In a language with strict a comma-as-separator rule you can
>>> get this benefit by placing the comma before new items rather
>>> than after existing items:
>>>
>>> enum {	FOO
>>> 	,FIE
>>> 	,FUM
>>> };
>>>
>>> but luckily C doesn't need this perversion.
>>
>> Only since C99 (but GNU C never needed it either).
>
> C had this for much longer than 99. Borland Turbo C from around 1990
> (which you can expect to be C89 if you have luck) also allows , at the end.

C89 definitely does not allow a comma at the end of the enumerator list
(only at the end of the initializer list).  If Borland C allows it in
its strict C89 mode (if it has such a thing) then it is buggy.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."