On 2014-11-08 19:06, Trevor Vaughan wrote:
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
It depends very much how the methods are phrased and what they do.
And there are several ways to to do that...
return nil unless it_is_ok?
return nil if bad_things_happened?
Personally I avoid designing with use of "and"/"or" and would not mind a
bit if they were not allowed anywhere. But I recognize it could be very
irritating for someone that is used to phrasing/organizing code a
different way.
- henrik
On Mon, Aug 11, 2014 at 1:01 PM, Rahul Gopinath <ra...@puppetlabs.com
<mailto:ra...@puppetlabs.com>> 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
<henrik.lindb...@cloudsmith.com
<mailto:henrik.lindb...@cloudsmith.com>> 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
>> <henrik.lindb...@cloudsmith.com
<mailto:henrik.lindb...@cloudsmith.com>> wrote:
>>>
>>> On 2014-11-08 2:01, Kylo Ginsberg wrote:
>>>>
>>>>
>>>> On Sat, Aug 9, 2014 at 9:45 AM, Henrik Lindberg
>>>> <henrik.lindb...@cloudsmith.com
<mailto:henrik.lindb...@cloudsmith.com>
<mailto:henrik.lindb...@cloudsmith.com
<mailto:henrik.lindb...@cloudsmith.com>>>
>>>>
>>>> wrote:
>>>>
>>>> On 2014-09-08 24:13, Andy Parker wrote:
>>>>
>>>> On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath
>>>> <ra...@puppetlabs.com <mailto:ra...@puppetlabs.com>
<mailto:ra...@puppetlabs.com <mailto:ra...@puppetlabs.com>>
>>>> <mailto:ra...@puppetlabs.com
<mailto:ra...@puppetlabs.com> <mailto:ra...@puppetlabs.com
<mailto:ra...@puppetlabs.com>>>>
>>>> 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 puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
>>> 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 puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
> 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 puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
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
<https://groups.google.com/d/optout>.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com <mailto:tvaug...@onyxpoint.com>
-- 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 puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUFnkiukUm6xQm6jSjFzjmGULgK2JOQ-UgPtqJ9v8GCcQ%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUFnkiukUm6xQm6jSjFzjmGULgK2JOQ-UgPtqJ9v8GCcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lsb1ng%24lon%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
