Learning precedence is a good thing. Obviously, as with any computer language this is important, and there's just enough quirks with perl's table (from it's unique operators) that you do need to learn where these fit in.

Learning how to use parathesis less and operator precedence more is, IMO, equivalent to the progress one makes in their prose writing as they advance through school. Sentence structure become more advance, less common words are used more, etc. This is partially due not only for the writer to able to convience his/her message better, but reflexively, for the writer to review and critique their own work. If the writer users structure and words too complexe for them to understand, they usually go back and change it. For example, a common example is the compound sentence; it's nearly always better to go back and break that into multiple sentences if the meaning is not readily understood. However, well-written prose writers can effectively use complex sentences because they have learned the subtlies needed to help readers parse and understand the sentence correctly.

With any language with operations, the same is true; the typical pattern is for most new programmers to parathesize every expression so that the programmers him/herself can understand what the code does when they review it again. But as the coder progresses, and understands where parenthesis are unnecessary, they will start to avoid them, sometimes resulting in cleaner code that still can be understood by all. But there are still times that I would consider using parenthesis in order to convey understanding in a program even though I could not use them and get the same expected result. For example, to test whether a point ($x, $y) might be in a bounding box, I could use:

if ( ($x >= $x_min ) && ($x <= $x_max) && ($y >= $y_min) && ($y <= $y_
+max) ) { ... }
[download]

Or I could use:

if ( $x >= $x_min && $x <= $x_max && $y >= $y_min && &y <= &y_max ) { 
+... }
[download]

Or I could use:

if ( ( $x >= $x_min && $x <= $x_max ) && ( $y >= $y_min && $y <= $y_ma
+x ) ) { ... }
[download]

While all 3 of these will do the same inequality tests, I personally feel that the last option is the easiest to understand at a glance (that is, requiring minimal parsing of code to understand the intent of the programmer). The first case has a lot of parenthesis and it's easy to see what the specific tests are but not the whole picture, while the second case, it takes a bit of time to figure out what are the test conditions and what are the boolean operators.

But a lot of this boils down to personal preference, the coder's workplace environment, and how much maintainence and code upkeep will be done when the programmer is long gone. If I was in a shop with several perl newbies, I'd be tempted to use option 1 above over option 3 as a new programmer would understand it better (breaking the complexe into several smaller parts). But if the code was only for my use, it would most likely be 2.

So learning the operator precedence table is important. Knowing how to use parenthesis is important. But one of the defining qualities of a good programmer is one that knows how to combine these aspects into code that easily flows from the perverbal page to the reader's mind without syntax getting in the way. Removing all parenthesis for less characters in a file is a nice worthy goal , but the end result may not be as clear as one that uses just the right amount of parenthesis to help convey meaning.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.