qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 01/16] net: Add a hub net client
Date: Mon, 23 Jul 2012 18:33:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0

Am 23.07.2012 17:23, schrieb Stefan Hajnoczi:
> On Mon, Jul 23, 2012 at 4:16 PM, Laszlo Ersek <address@hidden> wrote:
>> On 07/23/12 16:52, Stefan Hajnoczi wrote:
>>> On Mon, Jul 23, 2012 at 3:05 PM, Laszlo Ersek <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]