Yes, fine by me. This is the convention that I normally use, but I don’t think that I have mentioned that to other people, so we might not all be sticking to this.
I do use _rec for a record, if I feel that it needs distinguishing explicitly. I’d prefer that we allowed vm or vm_rec for a record (that would give us less to fix up, apart from anything else!) Cheers, Ewan. From: openstack-xenapi-bounces+ewan.mellor=citrix....@lists.launchpad.net [mailto:openstack-xenapi-bounces+ewan.mellor=citrix....@lists.launchpad.net] On Behalf Of Chris Behrens Sent: 06 March 2011 04:43 To: Rick Harris Cc: openstack-xenapi@lists.launchpad.net Subject: Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme Totally agree. On Mar 5, 2011, at 8:26 PM, Rick Harris <rick.har...@rackspace.com<mailto:rick.har...@rackspace.com>> wrote: Reading through the XenAPI virt-layer code, I've noticed there is some inconsistency in how we name variables, in particular, how we distinguish between the three kinds of object references that XenAPI exposes: 1. Opaque references 2. UUIDs 3. Records In some of the code, 'vm' means that we're working with a VM record object; in others, it means we're working with an opaque reference. For our own sanity, I propose that we adopt the following convention (which currently is used by some--perhaps most-- of the code): 1. Opaque references should be suffixed with "_ref". e.g.: "vdi_ref" or "vm_ref" 2. UUIDs should be suffixed with "_uuid". e.g.: "vbd_uuid" or "sr_uuid" 3. Records should not have a suffix[1]. e.g.: "vm" or "vdi" If there is general agreement to this plan, we should create a bug in Launchpad to rename all of the currently mis-named variables to use the new naming scheme. Ordinarily I would have made this change without appealing to the list (since it doesn't seem controversial), but, in the interest of having this convention well-known/maintained, it's probably be better to get explicit buy in from everyone who works with the code. Thoughts? ---- [1] An alternative is to use "_rec" ("vm_rec"). That's very explicit, which is good, but, not necessary since refs and uuid cases are qualified. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com<mailto:ab...@rackspace.com>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net<mailto:openstack-xenapi@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
