[openstack-dev] [nova] Proposal new hacking rules
Sahid Orentino Ferdjaoui
sahid.ferdjaoui at redhat.com
Mon Nov 24 10:16:10 UTC 2014
On Fri, Nov 21, 2014 at 01:52:50PM -0500, Matthew Treinish wrote:
> On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
> > Hey,
> > I am not a Nova developer but I still have an opinion.
> > >Using boolean assertions
> > I like what you propose. We should use and enforce the assert* that best matches the intention. It's about semantic and the more precise we are, the better.
> > >Using same order of arguments in equality assertions
> > Why not. But I don't know how we can write a Hacking rule for this. So you may fix all the occurrences for this now, but it might get back in the future.
Let write this rules in HACKING.rst, developers and reviewers are
expected to read it.
> Ok I'll bite, besides the enforceability issue which you pointed out, it just
> doesn't make any sense, you're asserting 2 things are equal: (A == B) == (B == A)
> and I honestly feel that it goes beyond nitpicking because of that.
> It's also a fallacy that there will always be an observed value and an
> expected value. For example:
> self.assertEqual(method_a(), method_b())
> Which one is observed and which one is expected? I think this proposal is just
> reading into the parameter names a bit too much.
Let developer to know about what values was expected when he broke a
test during his development without looking into the testcase code.
Operators can also want to know about what values was
expected/observed without reading the code when executing tests.
> > >Using LOG.warn instead of LOG.warning
> > I am -1 on this. The part that comes after LOG. (LOG.warning, LOG.error, LOG.debug, etc) is the log level, it's not a verb. In syslog, the well-known log level is "warning" so the correct method to use here is, imo, log.warning().
Well I have choiced 'warn' because there is less changes but I do not
have any preference, just want something clear from Nova.
> > Have you concidered submitting this hacking rules to the hacking project here : https://github.com/openstack-dev/hacking ? I am sure these new rules makes sense on other openstack projects.
Make them accepted by Nova community first before to think about other
> > Jordan
> > ----- Original Message -----
> > From: "Sahid Orentino Ferdjaoui" <sahid.ferdjaoui at redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> > Sent: Friday, November 21, 2014 5:57:14 PM
> > Subject: Re: [openstack-dev] [nova] Proposal new hacking rules
> > On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
> > > On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui <
> > > sahid.ferdjaoui at redhat.com> wrote:
> > >
> > > > This is something we can call nitpiking or low priority.
> > > >
> > >
> > > This all seems like nitpicking for very little value. I think there are
> > > better things we can be focusing on instead of thinking of new ways to nit
> > > pick. So I am -1 on all of these.
> > Yes as written this is low priority but something necessary for a
> > project like Nova it is.
> > Considered that I feel sad to take your time. Can I suggest you to
> > take no notice of this and let's others developers working on Nova too
> > do this job ?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev