Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client

From: "Andreas Färber" <afaerber@suse.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Erik Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org, Zhi Yong Wu <wuzhy@cn.ibm.com>,
	Blue Swirl <blauwirbel@gmail.com>,
	Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client
Date: Mon, 23 Jul 2012 18:33:43 +0200	[thread overview]
Message-ID: <500D7CE7.9040903@suse.de> (raw)
In-Reply-To: <CAJSP0QULUhcMzyet9eZzki8KMztRiY9czGWyMbrQS=qbjHKZnA@mail.gmail.com>

Am 23.07.2012 17:23, schrieb Stefan Hajnoczi:
> On Mon, Jul 23, 2012 at 4:16 PM, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 07/23/12 16:52, Stefan Hajnoczi wrote:
>>> On Mon, Jul 23, 2012 at 3:05 PM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>>>> The idea is, rather than
>>>>
>>>>     unsigned int id = hub->num_ports++;
>>>>
>>>> it should say
>>>>
>>>>     unsigned int id;
>>>>     /* ... */
>>>>     id = hub->num_ports++;
>>>
>>> "Be careful to not obfuscate the code by initializing variables in the
>>> declarations.  Use this feature only thoughtfully.  DO NOT use
>>> function calls in initializers."
>>>
>>> This?
>>>
>>> Do you know the rationale?  It's not clear to me how this "obfuscates" the code.
>>
>> I think the rationale is that (a) people tend to reorganize definitions,
>> and the expressions in the initializer lists may depend on the original
>> order, (b) even worse with removal of variables, (c) many people have a
>> "conceptual divide" between the definition block and the logic below it,
>> and the first should set constant defaults at most. (Naturally this
>> prevents C99/C++ style mixing of definitions and code as well, at least
>> without explicit braces.)
>>
>> I'm one of those people, but again I'm not sure if qemu has any
>> guideline on this.
>>
>>
>>> Messing around with side-effects in a series of variable declarations
>>> with intializers could be bug-prone.  But here there is only one
>>> initializer so it's not a problem.
>>>
>>> Regarding QEMU, there's no coding style rule against initializers.
>>> Personally I think that's a good thing because it keeps the code
>>> concise - people reading it don't have to keep the declaration in
>>> their mind until they hit the initializer later on.
>>
>> Well I keep the definitions at the top of the block so I can very easily
>> return to them visually (and be sure they do nothing else than define
>> variables / declare externs), but it's getting philosophical :)
>>
>> I have nothing against this initializer as-is, I just wanted to voice
>> *if* there's such a guideline in qemu *then* it should be followed :)
> 
> Yes, I understand - it's a question of style or flamewar fodder :).  I
> double-checked that there is no guideline in ./CODING_STYLE and
> ./HACKING.

Hm, I'm not so much into those documents [cc'ing Blue], but we used to
be stricter about ANSI C some years back (which iirc forbids
non-constant expressions in initializers?). FWIW we have since switched
to C99 struct initializers and use QOM cast macros (that translate to a
function call) in initializers. -ansi -pedantic is unlikely to get far.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg