On 10/06/2017 05:34 AM, Michal Privoznik wrote:
> On 10/05/2017 10:23 PM, John Ferlan wrote:
>> Rather than accessing privconn->pools.objs[i] in the for loop,
>> let's use an @obj variable to make it easier to read the code.
>>
>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>> ---
>> src/test/test_driver.c | 30 ++++++++++++++++--------------
>> 1 file changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
>> index a1a74b8bd1..e84acf3228 100644
>> --- a/src/test/test_driver.c
>> +++ b/src/test/test_driver.c
>> @@ -4905,27 +4905,28 @@ testStorageVolLookupByKey(virConnectPtr conn,
>> const char *key)
>> {
>> testDriverPtr privconn = conn->privateData;
>> + virStoragePoolObjPtr obj;
>
> How about s/obj/poolObj/ or something so that one know just from looking
> whether obj refers to pool or volume. But I don't care that much.
>
> Michal
>
I think I've now gone with just obj for everything for so long that it's
been more common. Also, there's no such thing as a virStorageVolObjPtr
yet, so I think I'd rather just stick with obj unless the all the
storage pool tests change to use poolObj. I can do that, but other
similar variable name change only patches have been widely disliked
throughout this effort so I've tried hard not to add them in these more
recent patches. In my original local branches - all there was a patch
for each of the storage backends which changed virStoragePoolObjPtr pool
to be obj, but I doubt those will ever see the list ;-)
I'm going to keep it as obj - I can do a follow up to make the naming
consistent throughout, but I kind of doubt it'll get much support.
Tks for the quick look -
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
