[openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

David Stanek dstanek at dstanek.com
Tue Jan 12 14:09:48 UTC 2016

On Tue, Jan 12, 2016 at 8:51 AM, Amrith Kumar <amrith at tesora.com> wrote:

> I've tagged this message with the projects impacted by a series of change
> sets:
>         [trove] https://review.openstack.org/#/c/266220/
>         [neutron] https://review.openstack.org/#/c/266156/1
>         [cinder] https://review.openstack.org/#/c/266099/2
>         [swift] https://review.openstack.org/#/c/266185/1
>         [ceilometer] https://review.openstack.org/#/c/266211/1
>         [nova] https://review.openstack.org/#/c/266143/2
>         [keystone] https://review.openstack.org/#/c/266203/2
>         [sahara] https://review.openstack.org/#/c/266230/1
>         [glance] https://review.openstack.org/#/c/266192/1
>         [neutron-lbaas] https://review.openstack.org/#/c/266181/1
> I would like the guidance of the developer community in figuring out how
> to proceed with this change, and changes like this.
> The change, in essence changes a construct of the kind:
> if var > 0:
>         ... something ...
> To
> if var:
>         ... something ...
> In a couple of cases, it also changes messages from (for example, in Trove)
> "Limit value must be > 0" to
> "Limit value must be greater than zero"
> My question to the ML is this, should stylistic changes of this kind be
> handled in a consistent way across all projects, maybe with a hacking rule
> and some discussion on the ML first? After all, if this change is
> worthwhile, it is worth ensuring that this construct that we are seeking to
> eliminate, does not reenter the code base.

The code above is not stylistic in nature.  It actually changes the
semantics of the check. This should not be done blindly across the board.

In the first case it looks for a value to be greater than a constant. In
the second case it looks for a value to have a truthy value.

> For what it is worth, I agree with Vitaly Grindev [sahara, in review
> https://review.openstack.org/#/c/266230/1]. I think the code before the
> change was more intuitive and readable.

Only if the code is correct. In that review I saw you changing "len(x) > 0"
to "len(x)" and that's fine. But you also changed a check looking at the
status code from a conductor call to no longer allow negative return
values. I have no idea if it returns negative numbers, but in this case I
would guess the "> 0" had a purpose.

blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160112/d0f5f466/attachment.html>

More information about the OpenStack-dev mailing list