http://www.perlmonks.org?node_id=1001211


in reply to Re^3: Regex help/ Lua parse
in thread Regex help/ Lua parse

Thank you for your response. Updated the reference to Mastering Regular Expressions above. Can you please explain how the previous code was superior? I see the indentation problems that you are referring to, and I tried to be sure to follow the guidelines specified in perlstyle, i.e. 4 space indentations, curly brackets on same line or lined up vertically, space around most operators. Should I have used

 $theme_table{$1} = $2 if (/regex/); instead of  if (/regex/) { $theme_table{$1}

or

foreach my $table (@_) { foreach my $key (sort keys %$table) { print "$key => $table->{$key}\n" } print "\n"; }
instead of
foreach my $table (@_) { foreach my $key (sort keys %$table) { print " $key => $tabl +e->{$key}\n" } print "\n"; }

If you could clarify exactly where it is that I'm missing the mark stylistically it would be greatly appreciated. I think good style is the most difficult thing to learn out of a book. Thanks again for your help.

Replies are listed 'Best First'.
Re^5: Regex help/ Lua parse
by kcott (Archbishop) on Oct 27, 2012 at 17:43 UTC

    Compare your original version (with all regexes reduced to regex to alleviate noise)

    sub buildTables { while (<>) { if (/regex/) { $theme_table{$1} = $2 } if (/regex/) { $taglist_table{$1} = $2 } if (/regex/) { $menu_table{$1} = $2 } } #print Dumper \%theme_table; #print Dumper \%taglist_table; #print Dumper \%menu_table; }

    with this alternative version

    sub buildTables { while (<>) { if (/regex/) { $theme_table{$1} = $2 } if (/regex/) { $taglist_table{$1} = $2 } if (/regex/) { $menu_table{$1} = $2 } } }

    Which looks clearer to you? Is the closing brace of the while loop more or less obvious to you now? How about providing me with some examples of code that looks like yours.

    -- Ken

      Aaah. I see. It seems much more obvious to me with the reduced regexes. I've never used such extensive regexes and I think I may have been letting myself get overwhelmed and distracted by the length and complexity of these statements in comparison to the shorter more basic code I've been learning with. So in essence,
      if (x = y) { print x; }
      and, in simple situations
      if (x = y) { print x; }
      are ok, but
      if (x = y) { print x; }
      is not. In this stripped down form I can see how the last example, although interpreted properly by Perl, can look like a random  if (x = y) and an unrelated block of { print x; }. I'm not entirely sure of what kind of examples you are asking for, but from this node:
      ...
      if ($Age < 13) && ($Age > 0)) { print "What are you doing here, $firstName? This Web site is strictly PG-13. Shame on you for being so naughty as to come here!"; } elsif ($Age < 18) && ($Age > 12)) { print "Not to long ago, we’d have have chased you away from our Web site. But now that you’re a teenager and mature enough for PG-13 materials, we’re glad to see you $firstName."; }
      ...
      has the same qualities as my code and could be cleaned up (focusing on the indentation and curly braces) by saying:
      if (($Age < 13) && ($Age > 0)) { print "content"; } elsif (($Age < 18) && ($Age > 12)) { print "content"; }
      or even:
      if (($Age < 13) && ($Age > 0)) { print "content"; } elsif (($Age < 18) && ($Age > 12)) { print "content"; }
      Thank you again for taking time out to help me grasp the fundamentals. Please let me know if I am missing your point. I enjoy Perl (and learning programming in general) and feel I have been progressing rather quickly, but I want to squash bad habits and form a good foundation in style and understanding before moving to some of the more complex concepts and modules in Perl.

        Another book you may be interested is Perl Best Practices Standards and Styles for Developing Maintainable Code. Amongst all its other good advice, this has an entire chapter devoted to guidelines for code layout.

        Be aware that this book provides guidelines; not rules. Also, as it was released in 2005, it won't make references to features added in more recent versions of Perl (perlhist provides a history of Perl releases, if you're interested).

        -- Ken