in reply to Too Many Ways To Do It
A really bad programmer may hear a problem and start working on it before even having heard the full problem through.
And it isn't Perl that is at fault. Every language will present you with choices, and the tradeoffs are not always obvious. I personally learn about the tradeoffs from sites like this, books, conversations with other people, and so on.
BTW a random tip. I find it hard glancing at your code to see what arguments your function accepts in what order. That is why most people put function processing into its own section. Consider the following slightly modified version to see what I mean:
Isn't it easier there to glance at the function and see how it is supposed to be used? Now personally I would suggest putting everything in the template constructor if possible. Aim for having as few elements of control as possible. If you can do that then there is no need to bother naming temporaries:sub Send_Header { my %passed_args; @passed_args{'header', 'to', 'subject'} = @_; my $header_tmpl = HTML::Template->new( filename => 'header.tmpl' ); $header_tmpl->param( %passed_args, date => substr(scalar gmtime time, 0, 10), ); print $header_tmpl->output(); }
That method of chained method calls can be hard to read if you are not used to it, but think of it as being like a pipeline and you won't go too far wrong. Also it would be nicer if there wasn't a mix between the functionally written print, and the chain, but I don't find it too confusing.sub Send_Header { my %passed_args; @passed_args{'header', 'to', 'subject'} = @_; print HTML::Template->new( filename => 'header.tmpl', date => substr(scalar gmtime time, 0, 10), %passed_args, )->output(); }
And I would personally prefer to see a custom written date formatting function rather than the inlined version of gmtime which someone has to run to see what it does...
And so it goes...
|
|---|