Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guideline proposal: Use proc.call() over proc[] or proc.() #205

Closed
dirkbolte opened this issue Jul 28, 2013 · 4 comments
Closed

Guideline proposal: Use proc.call() over proc[] or proc.() #205

dirkbolte opened this issue Jul 28, 2013 · 4 comments

Comments

@dirkbolte
Copy link
Contributor

There are three different ways to call a proc or lambda:

l = ->(v)  { puts v }
l[1]
l.(1)
l.call(1)

According to http://www.ruby-doc.org/core-2.0/Proc.html , they all seem to be equivalent.

l[1] looks like addressing an array index instead of calling a method, therefore it does not do what I would expect from reading the code.
´l.(1) looks like a method call where the method name is missing. When I saw it for the first time, it was hard to understand it. This way of calling a proc is just mentioned as syntactic sugar in two method documentations, so if you are not familiar with this construct, it is most likely just confusing and thereby impacts readability.
l.call(1) is pretty easy to understand. Although it uses more characters than the other two examples, I prefer to have easily readable code.

@fuadsaud
Copy link
Contributor

Hum, I like #(), but I agree that #call is more readable.

@equivalent
Copy link
Contributor

l.call(1) looks more object oriented, where l.(1) looks more like something taken from Brainf**k language

so +1

@lee-dohm
Copy link
Contributor

lee-dohm commented Aug 2, 2013

👍 I agree that #call is the most readable and is probably the best choice in the common case.

@bbatsov
Copy link
Collaborator

bbatsov commented Aug 16, 2013

👍 I'd suggest creating a PR for that rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants