# Highlighter for operator precedence

**URL:** <https://www.ruby-forum.com/t/highlighter-for-operator-precedence/92472>\
**Category:** Ruby\
**Created:** [April 19, 2007, 8:59pm UTC](https://www.ruby-forum.com/t/highlighter-for-operator-precedence/92472 "2007-04-19T20:59:43Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mschwab](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/59ef9b/32.png) [@mschwab](https://www.ruby-forum.com/u/mschwab)\
**Post date:** [April 19, 2007, 8:59pm UTC](https://www.ruby-forum.com/t/highlighter-for-operator-precedence/92472/1 "2007-04-19T20:59:43Z")

</div>

Is there a web site that will highlight code to show who Ruby will send  
each message to? I like playing around with parentheses and the ternary  
operator, and I want to explore the precedence distinction between {}  
and do end.

Some find it unnecessary to remove all implied parentheses and still  
strive for one-liners, but I find it makes the code more readible, and  
more emulatable. I think a visual tool for learning these rules could  
make Ruby more accessible.

Once that were ready, would it not be a small step to make a tool that  
strips the unnecessary parens itself?

---

<div class="post-metadata">

**Author:** ![mschwab](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/59ef9b/32.png) [@mschwab](https://www.ruby-forum.com/u/mschwab)\
**Post date:** [April 20, 2007, 11:01am UTC](https://www.ruby-forum.com/t/highlighter-for-operator-precedence/92472/2 "2007-04-20T11:01:04Z")

</div>

On 19.04.2007 20:59, Mike S. wrote:

> Is there a web site that will highlight code to show who Ruby will send  
> each message to? I like playing around with parentheses and the ternary  
> operator, and I want to explore the precedence distinction between {}  
> and do end.

I do not know such a site. But you can do something like this to see  
what happens:

irb(main):011:0\> baz=1  
=\> 1  
irb(main):012:0\> def foo(\*a) [:foo, a] end  
=\> nil  
irb(main):013:0\> def bar(\*a) [:bar, a] end  
=\> nil  
irb(main):014:0\> foo bar baz  
(irb):14: warning: parenthesize argument(s) for future version  
=\> [:foo, [[:bar, [1]]]]  
irb(main):015:0\> foo bar(baz)  
=\> [:foo, [[:bar, [1]]]]  
irb(main):016:0\> foo(bar baz)  
(irb):16: warning: parenthesize argument(s) for future version  
=\> [:foo, [[:bar, [1]]]]  
irb(main):017:0\>

> Some find it unnecessary to remove all implied parentheses and still  
> strive for one-liners, but I find it makes the code more readible, and  
> more emulatable. I think a visual tool for learning these rules could  
> make Ruby more accessible.

Well, if it suits you well why don’t you just leave the parens in? From  
time to time I tend to use parens in boolean expressions even though I  
know that && binds before || just to not have to worry about precedence.

> Once that were ready, would it not be a small step to make a tool that  
> strips the unnecessary parens itself?

Apparently nobody has bothered so far to do it so it must be a minor  
problem. 🙂

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![mschwab](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/59ef9b/32.png) [@mschwab](https://www.ruby-forum.com/u/mschwab)\
**Post date:** [April 20, 2007, 4:40pm UTC](https://www.ruby-forum.com/t/highlighter-for-operator-precedence/92472/3 "2007-04-20T16:40:22Z")

</div>

On 4/19/07, Mike S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Once that were ready, would it not be a small step to make a tool that  
> strips the unnecessary parens itself?

If an expression is so complicated you need a tool to strip  
“unnecessary”  
parens from it, what makes you think you won’t need a tool to put the  
parens  
back in when you go to read it again and figure out what it does? A tool  
to  
find and exploit the dark corners of ruby’s precedence rules to avoid  
parentheses seems to be missing the forest for the trees. If you have a  
complicated expression with a lot of parens, maybe its time to name some  
of  
those sub-expressions, not automate its obfuscation.