Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Monday 11 October 2010 13:20:07 Dr.Ruud wrote:
> On 2010-10-08 16:52, Shlomi Fish wrote:
> > my ($arg1, $arg2, $arg3 ... ) = @_;
>
> Bad pattern: numbered names.
Well, thanks for trimming out so much of my message.
In any case, naturally, I didn't intend that you actually name the arguments
as "$arg1" , "$arg2" , "$arg3" , etc. literally. This was just done for
clarity.
An actual use case may be:
[code]
sub send_message_to_user
{
my $self = shift;
my $user = shift;
my ($format, $format_params) = @_;
# Do some sanity checks
if (ref($format) ne "")
{
confess "Format is not a string!";
}
if (ref($format_params) ne "ARRAY")
{
confess "Format parameters should be an array reference.";
}
return $self->_get_user($user)->send_message(@_);
}
[/code]
A little contrieved, but I've done it before.
Naturally, naming your variables as $name1, $name2, $name3 is indicative that
you need a hash or an array. See varvarname:
http://perl.plover.com/varvarname.html
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html
She's a hot chick. But she smokes.
She can smoke as long as she's smokin'.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On 2010-10-08 16:52, Shlomi Fish wrote: my ($arg1, $arg2, $arg3 ... ) = @_; Bad pattern: numbered names. -- Ruud -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On 2010-10-10 03:09, Ron Bergin wrote: Have you considered including an example were it would be appropriate to use the C-style for loop, such as when the iterator needs to change by some value other than 1? Bad data structure. -- Ruud -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Oct 10, 12:59 am, shlo...@iglu.org.il (Shlomi Fish) wrote: > On Sunday 10 October 2010 03:09:21 Ron Bergin wrote: > > > > > On Oct 7, 3:07 pm, shlo...@iglu.org.il (Shlomi Fish) wrote: > > > Hi all, > > > > after being tired of telling Perl newcomers about the same problems with > > > their code times and times again, I've decided to create this page > > > detailing "Perl Elements to avoid": > > > >http://perl-begin.org/tutorials/bad-elements/ > > > [quote] > > C-style for loops > > > Some beginners to Perl tend to use C-style-for-loops to loop over an > > array's elements: > > [/quote] > > > Have you considered including an example were it would be appropriate > > to use the C-style for loop, such as when the iterator needs to change > > by some value other than 1? > > Well, in this case, PBP recommends to use a while/continue loop: > This is one area where I disagree with PBP, at least in most cases. The while/continue loop is more verbose and to the beginner more difficult to understand. > > But it's a good idea to show both versions. Thanks! I would agree that showing both versions would be best. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Sun, Oct 10, 2010 at 3:59 AM, Shlomi Fish wrote:
> Well, in this case, PBP recommends to use a while/continue loop:
>
> [code]
> for (my $i = 0; $i < $n ; $i += 2)
> {
> print "$i\n";
> }
> [/code]
>
> into:
>
> [code]
> {
> my $i = 0;
>
> while ($i < $n)
> {
> print "$i\n";
> }
> continue
> {
> $i += 2;
> }
> }
> [/code]
Can somebody please explain why the latter would be preferred to the
former? Coding mostly with C#, C++, and C; The latter looks much
uglier and much more error prone to me. Anyone familiar with a C-like
language should be quite comfortable with a C-style for-loop. If you
need $i anyway then I don't see the harm. If it's a performance
concern then I would cry premature optimization..
--
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Sunday 10 October 2010 03:09:21 Ron Bergin wrote:
> On Oct 7, 3:07 pm, shlo...@iglu.org.il (Shlomi Fish) wrote:
> > Hi all,
> >
> > after being tired of telling Perl newcomers about the same problems with
> > their code times and times again, I've decided to create this page
> > detailing "Perl Elements to avoid":
> >
> > http://perl-begin.org/tutorials/bad-elements/
>
> [quote]
> C-style for loops
>
> Some beginners to Perl tend to use C-style-for-loops to loop over an
> array's elements:
> [/quote]
>
> Have you considered including an example were it would be appropriate
> to use the C-style for loop, such as when the iterator needs to change
> by some value other than 1?
Well, in this case, PBP recommends to use a while/continue loop:
[code]
for (my $i = 0; $i < $n ; $i += 2)
{
print "$i\n";
}
[/code]
into:
[code]
{
my $i = 0;
while ($i < $n)
{
print "$i\n";
}
continue
{
$i += 2;
}
}
[/code]
But it's a good idea to show both versions. Thanks!
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
Optimising Code for Speed - http://shlom.in/optimise
She's a hot chick. But she smokes.
She can smoke as long as she's smokin'.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Oct 7, 3:07 pm, shlo...@iglu.org.il (Shlomi Fish) wrote: > Hi all, > > after being tired of telling Perl newcomers about the same problems with their > code times and times again, I've decided to create this page detailing "Perl > Elements to avoid": > > http://perl-begin.org/tutorials/bad-elements/ > [quote] C-style for loops Some beginners to Perl tend to use C-style-for-loops to loop over an array's elements: [/quote] Have you considered including an example were it would be appropriate to use the C-style for loop, such as when the iterator needs to change by some value other than 1? -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On 10/08/2010 12:07 AM, Shlomi Fish wrote: > Hi all, > > after being tired of telling Perl newcomers about the same problems with > their > code times and times again, I've decided to create this page detailing "Perl > Elements to avoid": Nobody is forcing you to tell anyone anything. Teaching and guidance is a task that, at times, means repeating the same sage advice to many different people, often having to repeat the same suggestions to the letter. While your contribution is most appreciated, and your efforts are commendable, a slightly more positive tone is more appropriate to a beginners list. -- Erez Observations, not opinions. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
We are stuck on perl 5.8.n on the better systems, 5.6 on some older Solaris boxes. Sad but true. When working with significant quantities of data some of those trivial performance hits can add up - quickly! I'd love to see (I'd contribute to) an updated fast performance article (hint hint). Jonas Bull -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Friday 08 October 2010 15:03:47 Jonas Bull wrote:
> Only one thing I'd mention:
>
> Under "Subroutine Arguments Handling" you offer $var=shift; as a
> better alternative to $var=$_[n] - which it is - but it is a
> (admittedly slight) performance hit vs ($var,$var2,...)=...@_;
>
Well, one good use case for «my $var = shift;» is this:
sub my_method
{
my $self = shift;
my ($arg1, $arg2, $arg3 ... ) = @_;
.
.
.
return $self->_other_method(@_);
}
In perl-5.10.0 before perl-5.10.1 came out, there was a significant slowdown
in the execution of one of the forms, but I don't remember which one.
In any case, both forms are acceptable and make for good practices, and the
performance hit is not significant.
>
> Otherwise, pretty useful info. I'm forwarding the link to the rest of
> my group. :-)
>
Thanks!
Regards,
Shlomi Fish
> Jonas Bull
>
--
-
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap
She's a hot chick. But she smokes.
She can smoke as long as she's smokin'.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
Only one thing I'd mention: Under "Subroutine Arguments Handling" you offer $var=shift; as a better alternative to $var=$_[n] - which it is - but it is a (admittedly slight) performance hit vs ($var,$var2,...)=...@_; Otherwise, pretty useful info. I'm forwarding the link to the rest of my group. :-) Jonas Bull On Fri, Oct 8, 2010 at 7:31 AM, Shawn H Corey wrote: > On 10-10-08 06:10 AM, Shlomi Fish wrote: >> >> It's just that EOF is customary for that (presumable back to its root from >> shell). > > FYI: Actually, EOF dates all the way back to JCL. The alternative is EOD, > End Of Data. > > > -- > Just my 0.0002 million dollars worth, > Shawn > > Programming is as much about organization and communication > as it is about coding. > > The secret to great software: Fail early & often. > > Eliminate software piracy: use only FLOSS. > > -- > To unsubscribe, e-mail: beginners-unsubscr...@perl.org > For additional commands, e-mail: beginners-h...@perl.org > http://learn.perl.org/ > > > -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On 10-10-08 06:10 AM, Shlomi Fish wrote: It's just that EOF is customary for that (presumable back to its root from shell). FYI: Actually, EOF dates all the way back to JCL. The alternative is EOD, End Of Data. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. The secret to great software: Fail early & often. Eliminate software piracy: use only FLOSS. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Friday 08 October 2010 01:41:01 John W. Krahn wrote:
> Shlomi Fish wrote:
> > Hi all,
>
> Hello,
Hi John,
>
> > after being tired of telling Perl newcomers about the same problems with
> > their code times and times again, I've decided to create this page
> > detailing "Perl Elements to avoid":
> >
> > http://perl-begin.org/tutorials/bad-elements/
>
>
> the ultimately wrong, insecure and/or outdated styles are:
>
> # Bareword filehandle (type glob), two arguments open (insecure) and no
> # error handling
> open INPUT, "<$filename";
>
>
> You say "outdated styles" implying more than one example but you don't
> show the other style i.e.:
>
> use vars qw/ $INPUT /;
> our $INPUT = $filename;
> open INPUT;
You don't need both use vars and our for the same variable.
>
> You say "wrong" and "insecure" which is incorrect if the file name is
> prefixed and postfixed correctly, as described in the documentation.
>
> $filename = "./$filename\0";
>
OK, but many people will avoid doing that (and I was not aware of it now), and
furthermore "./" (or "/") may not be very portable, and the three-args open is
generally much preferable. Better be safe than sorry.
>
>
> Make sure you never use bareword here documents < syntax, but people are never sure whether they are <<"EOF" or <<`EOF`.
>
>
> I am a "people" and I am very sure that < <<"EOF".
OK, I've changed "people" to "many people".
> And EOF is usually short for End-Of-File so why use it for a
> string delimiter?
It's just that EOF is customary for that (presumable back to its root from
shell). See:
http://www.google.com/codesearch?as_q=%3C%3CEOF&btnG=Search+Code&hl=en&as_package=&as_lang=&as_filename=&as_class=&as_function=&as_license=&as_case=
(short URL - http://xrl.us/bh33nx ).
Don't take it too literarly.
>
>
>
> Slurping a file (i.e: Reading it all into memory)
>
>
> You are missing some other examples:
>
> read $fh, my $contents, -s $fh;
>
> sysread $fh, my $contents, -s $fh;
I didn't see these examples in the wild a lot, but I'll add them.
>
>
>
> sub my_func
> {
> my ($prefix, $array_ref) = @_;
>
> foreach my $item (@{$array_ref})
> {
> print $prefix, ": ", $item, "\n";
> }
>
> return;
> }
>
>
> Why use a loop to print a list?
>
> sub my_func
> {
> my ($prefix, $array_ref) = @_;
>
> print $prefix, join( ": ", @$array_ref ), "\n";
>
> return;
> }
>
Your rewrite of my example has a few bugs - it will print all the items in
@$array_ref on one big line joined by ": " instead of in separate lines, and
would include the prefix only once. You can do something a bit better using
perldoc -f map , but a loop is good enough.
In any case, based on your input, I changed it to something less trivial:
sub calc_polynomial
{
my ($x, $coefficients) = @_;
my $x_power = 1;
my $result = 0;
foreach my $coeff (@{$coefficients})
{
$result += $coeff * $x_power;
}
continue
{
$x_power *= $x;
}
return $result;
}
print "(4*x^2 + 2x + 1)(x = 5) = ", calc_polynomial(5, [1, 2, 4]);
>
>
> An arbitrary C-style loop can be replaced with a while loop with a
> continue block.
>
>
> For example?
>
Well, I couldn't think of anything, but I guess I can grep my code for such
examples and include that or a similar one.
Thanks for your input!
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
Freecell Solver - http://fc-solve.berlios.de/
She's a hot chick. But she smokes.
She can smoke as long as she's smokin'.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
Shlomi Fish wrote: Hi all, Hello, after being tired of telling Perl newcomers about the same problems with their code times and times again, I've decided to create this page detailing "Perl Elements to avoid": http://perl-begin.org/tutorials/bad-elements/ the ultimately wrong, insecure and/or outdated styles are: # Bareword filehandle (type glob), two arguments open (insecure) and no # error handling open INPUT, "<$filename"; You say "outdated styles" implying more than one example but you don't show the other style i.e.: use vars qw/ $INPUT /; our $INPUT = $filename; open INPUT; You say "wrong" and "insecure" which is incorrect if the file name is prefixed and postfixed correctly, as described in the documentation. $filename = "./$filename\0"; Make sure you never use bareword here documents
Re: "Perl Elements to Avoid" Document on http://perl-begin.org/
On Fri, Oct 08, 2010 at 12:07:30AM +0200, Shlomi Fish wrote:
> after being tired of telling Perl newcomers about the same problems with
> their
> code times and times again, I've decided to create this page detailing "Perl
> Elements to avoid":
>
> http://perl-begin.org/tutorials/bad-elements/
>
> I've already mentioned it several times here in replies, but thought I'll
> create a top-level thread for discussion.
>
> Here's my to-do list for that page. More ideas are welcome:
Hello Shlomi,
Although it should probably go without saying, please be sure to mention
somewhere near the top that this is your opinion. Whilst many people
will agree with much of what you have written, or will write, I suspect
that hardly anyone, and perhaps only you yourself, will agree with
everything. Indeed, in some instances it is likely that some people
will consider that you are giving bad advice.
It might also be useful to note that you are providing guidelines for
beginners, and that people should feel free to go against this advice
when they understand why they are doing so.
Making such implicit caveats explicit could help to soften the tone and
avoid confusion.
I've CCed this to the list because it probably also applies to the
majority of the cases where somone sends a "black and white" reply to
the list which isn't solving a specific problem ("Don't do that, do
this", or "always ...").
Perl is used for many different tasks, and often different problems will
suggest correspondingly different solutions. Or perhaps someone just
has a different style. Pointing out and correcting mistakes is, of
course, always welcome on the list, but it does seem that more and more
frequently we are straying into the area of style, and here, greater
care is required.
Thanks,
--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
