Hi, Shinobu, Fully agree with you that this is a dilemma situation: If we use full word, for example "availaibility_zone_aggregate", then the length of one line easily exceed 80 characters, especially if there are several indents, if we don't use short name, it's very difficult to make sure one clause in one line as far as possible. Even after we use shorter name, sometimes, this issue is still there :(
In the experience of development, using full name as far as possible to reduce the PEP8 naming convention prompt ion. But if the naming will make us hard to write one clause less than 80 characters(ensure one clause in one line), then sometimes the abbreviation has to be done to balance the code readability. How do you think about this? Best Regards Chaoyi Huang ( Joe Huang ) -----Original Message----- From: Shinobu Kinjo [mailto:[email protected]] Sent: Tuesday, April 05, 2016 9:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Tricircle] Naming convention Hi Chaoyi, Thank you for your reply. How about this: # tricircle/api/pod.py 94 aggregate = az_ag.create_ag_az(context, 95 ag_name=ag_name, 96 az_name=az_name) ... 161 ag = az_ag.get_ag_by_name(context, ag_name) Since there is zero impact on the system, you could ignore though. Cheers, Shinobu On Tue, Apr 5, 2016 at 10:08 AM, joehuang <[email protected]> wrote: > Hi, Shinobu, > > Thanks for your suggestion. When using PyCharm as the IDE, one issue is that > if we use abbreviation for the word to name the function or variables, there > is some PEP8 promotion that you'd better to name it in a whole word, but not > abbreviation. > > Best Regards > Chaoyi Huang ( Joe Huang ) > > > -----Original Message----- > From: Shinobu Kinjo [mailto:[email protected]] > Sent: Saturday, April 02, 2016 7:40 AM > To: joehuang; OpenStack Development Mailing List (not for usage > questions) > Subject: Re: [openstack-dev] [Tricircle] Naming convention > > One of examples is: > > """ > tricircle/db/api.py > """ > authorize_quota_class_context(context, class_name): > > # This could become: > > auth_quota_class_ctx(ctx, class_name): > > # If we put some comment for this, this also could become: > > """ > Function: Ensure a request has right permission to given the project. > @ctx: user context > @class: class name > """ > auth_quota_ctx(ctx, class): > > Point here is, honestly not only name but also appropriate length of comment. > What do you think? > > Cheers, > Shinobu > > > On Sat, Apr 2, 2016 at 8:20 AM, joehuang <[email protected]> wrote: >> yes, good idea, could you point out or report a bug which are not >> good naming. >> >> thanks. >> >> Sent from HUAWEI AnyOffice >> 发件人：shinobu.kj >> 收件人：openstack-dev, >> 时间：2016-04-02 06:21:50 >> 主题:[openstack-dev] [Tricircle] Naming convention >> >> Hi Team, >> >> Probably it's worth thinking of naming convention for classes, >> methods or whatever we define in source codes. >> >> Some names are lengthy and there might be no consistency. At the >> moment it's fine. But once this project gets growing, situation would >> become chaotic and could cause bugs. >> >> What do you think? >> >> Cheers, >> Shinobu >> >> -- >> Email: >> [email protected] >> GitHub: >> shinobu-x >> Blog: >> Life with Distributed Computational System based on OpenSource >> >> _____________________________________________________________________ >> _ ____ OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Email: > [email protected] > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Email: [email protected] GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
