comment on

Your code/style guide looks really good. A few notes:

Leave warnings on in production. They are often your only indication that something went wrong. And, if you're sharing your logspace with another app, you have bigger problems.
Don't use Error in production code. It does its work with closures, which can (and does) cause memory leaks. Better is to just do it yourself with eval/die. Example:
```
eval {
    # Code that might die
}; if ($@) {
    # Catch area
}
[download]
```
Perl 5.6+ even allows you to die with an object. (This is what Error utilizes. Read the code sometime, it's not that difficult.)
return undef; will not do what you want. Better is just return;. Here's an example why:
```
sub foo { return undef; }

my @x = foo();
if (@x) { print "foo() succeeded\n" } else { print "foo() failed\n";
[download]
```
You even talk about this, but don't realize the issue.
Importing isa() can be neat, but I would still use UNIVERSAL::isa(), anyways, just to be anal. Also, there are many classes that, for whatever reason, need to overload both can() and isa(). Be mindful of them.
You use the word "local" when discussing keeping variables with what they're working on. Use the word "lexical". local means something specific in Perl.
When talking about map, grep, sort, and conditionals, you refer to saving 600 bytes of memory. That's the first time in about 15 years I've seen someone talk about saving bytes of memory, other than my compulsory ASM class in college. bytes!! You seriously think that this is a reason for or against anything? If I'm worried about 600 bytes of RAM, I shouldn't be using Perl. Remember - Perl doubly-indirects every single variable. That's 8 extra bytes overhead, just to even start having a variable. (There's more to it than that ... it's actually like 40 bytes just to have space for a variable, let alone the actual values.)
The real reason to use post-ifs, as you call them, is to improve readability. You want to have the important bits on the left hand side, closest to the margin. That stands out more. Error conditions should be on the right, where they can get out of the way of reading the main flow of the code.
Don't use a regex to test against many values, use a hash. Not only does it improve readability, but you are documenting why you're testing against these thing. (And, it's faster.)
In your regex-in-a-map, you don't explain why it's important to have $_ at the end. It's because s/// returns the number of changes, not the value changed. (Plus, in your example, the stripping of surrounding whitespace should be in a function.)

I agree with map in your list -> hash example. However, it might be more readable as such:

# Create an ID to name hash
my %hash = map { $_->id, $_->name } @Objects;

Becomes:

# Create an ID to name hash
my %hash = map { $_->id => $_->name } @Objects;
[download]

The double boolean negative. Never heard of it. If I saw it, I'd want to hunt you down with an axe. Try $foo = $bar && 1; - simple, clean, and is used in more places.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

In reply to Re: Re: Perl applications by dragonchild
in thread Perl applications by rje

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.


P is for Practical
	PerlMonks