I prefer: cmd x or return nil
as opposed to, if x then return nil, just because it flows better. Technically, though, a standard should be standard even if it's a bit irritating at times and I think that this one might qualify. Trevor On Mon, Aug 11, 2014 at 1:01 PM, Rahul Gopinath <[email protected]> wrote: > Thanks, > So just to confirm, we can try to enforce method call parenthesis > in conditionals (Does any one else have any objections?) > > On a related note, As Adrien noted, there are a few legitimate use > cases for `and` and `or` keywords, where they function as control flow > operators, and help readability: e.g `cmd x or return nil` or `do_x or > raise 'error'`, which can be replaced with if/unless but I wonder how > much it will gain us in terms of readability. I think it would be nice > to leave them alone. Any thoughts in this regard? > > On Mon, Aug 11, 2014 at 8:50 AM, Henrik Lindberg > <[email protected]> wrote: > > On 2014-11-08 17:44, Rahul Gopinath wrote: > >> > >> I agree with leaving () out for the DSL usage. > >> > >> Are there any such instances of DSL usage within conditionals > >> (if/unless/while...)? If not, would you be in favor if we restrict the > >> enforcement to conditionals only? > >> > >> > > I think that would be rare (if at all in our code base at least). > > > > - henrik > > > > > >> > >> On Mon, Aug 11, 2014 at 7:00 AM, Henrik Lindberg > >> <[email protected]> wrote: > >>> > >>> On 2014-11-08 2:01, Kylo Ginsberg wrote: > >>>> > >>>> > >>>> On Sat, Aug 9, 2014 at 9:45 AM, Henrik Lindberg > >>>> <[email protected] <mailto: > [email protected]>> > >>>> > >>>> wrote: > >>>> > >>>> On 2014-09-08 24:13, Andy Parker wrote: > >>>> > >>>> On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath > >>>> <[email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>>> > >>>> wrote: > >>>> > >>>> While correcting AndOr, I come across methods calls such > >>>> as > >>>> `if > >>>> value.is_a? FixNum or value.is_a? Integer` > >>>> > >>>> How should we parenthesize it? is it `(value.is_a? > FixNum) > >>>> || > >>>> (value.is_a? Integer)` or should it be > >>>> `value.is_a?(FixNum) > >>>> || > >>>> value.is_a?(Integer)` ? > >>>> > >>>> > >>>> value.is_a?(FixNum) > >>>> > >>>> Parens around the method arguments are the clearest fix and > we > >>>> should > >>>> put them in everywhere IMO :) > >>>> > >>>> > >>>> +1, except in internal DSL like logic where it reduces > readability > >>>> > >>>> > >>>> I definitely agree on the parentheses example above. > >>>> > >>>> Wrt requiring parens around method arguments *everywhere*, I have to > >>>> admit I've wanted that at times when reading puppet code, but I also > >>>> suspect it would be very high touch and perhaps controversial. > >>>> > >>>> And it sounds like we don't have consensus on that one. Henrik, can > you > >>>> give an example or two where it would reduce readability? That might > >>>> help guide the discussion a bit. > >>>> > >>>> > >>> The first that comes to mind is spec tests - it feels like you are > using > >>> a > >>> different language than ruby, but it is really a bunch of method calls > >>> without parentheses. > >>> > >>> i.e. do you want to write it like this? > >>> > >>> context("this context") do > >>> it("the thingy can ...") do > >>> ... > >>> end > >>> end > >>> > >>> IMO, that adds no value at all. > >>> > >>> In models: > >>> > >>> class Program < PopsObject > >>> contains_one_uni 'body', Expression > >>> has_many 'definitions', Definition > >>> has_attr 'source_text', String > >>> has_attr 'source_ref', String > >>> has_many_attr 'line_offsets', Integer > >>> has_attr 'locator', Object > >>> end > >>> > >>> In the new function API: > >>> > >>> dispatch :handle_enumerable do > >>> param 'Any', :enumerable > >>> param 'Hash', :options > >>> end > >>> > >>> Enforcing () in places like these sort of goes against the idea of > using > >>> an > >>> internal DSL. > >>> > >>> > >>> - henrik > >>> > >>> -- > >>> > >>> Visit my Blog "Puppet on the Edge" > >>> http://puppet-on-the-edge.blogspot.se/ > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Puppet Developers" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to [email protected]. > >>> To view this discussion on the web visit > >>> > >>> > https://groups.google.com/d/msgid/puppet-dev/lsaiai%24f9r%241%40ger.gmane.org > . > >>> > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> > > > > > > -- > > > > Visit my Blog "Puppet on the Edge" > > http://puppet-on-the-edge.blogspot.se/ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/puppet-dev/lsaoop%24107%241%40ger.gmane.org > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CA%2BemFfzcMrOytP9zEy%3DS-rSET_12g0NDZwHmVULcZsK6S5n9-A%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUFnkiukUm6xQm6jSjFzjmGULgK2JOQ-UgPtqJ9v8GCcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
