"Perl Elements to Avoid" Document on http://perl-begin.org/

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/

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:

[quote]

* Add to the page about best practices:
- discuss commenting.
- refactoring:
- magic numbers.
- duplicate code.
- long functions and methods.
- accessing object slots directly
- use accessors.
- EEK
- pass items from one subroutine to another.
- use objects.
- assign them to slots.
- ^ and $ in regexes.
- ambiguous.
- better use \A and \z to mean start-of-string and end-of-string.
- with /m can be used for start-of-line / end-of-line.
- Law of Demeter
- Mixing tabs and spaces.
- Always add an explicit return from the subroutine.
- leading underscores ("_") for non-API methods and functions.
- print {$fh} @args instead of "print $fh @args" which is too easy to
miss.
- varvarname - using a variable as a different variable's name.
- http://www.stonehenge.com/merlyn/UnixReview/col52.html
- $object->new() to create a new instance.
- avoid using perlform - use Perl6::Form instead (also see the text
generation page).
- don't overuse $_ - it's prune to errors.
- C-style for loops.
- Always label your loops.
- Accessing the last element using $array[$#array] - use $array[-1]
instead.
- Array element: @array[$idx] instead of $array[$idx].
- modifying an array/hash while iterating over it.
[/quote]

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
List of Portability Libraries - http://shlom.in/port-libs

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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

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 - paul@pjcj.net
http://www.pjcj.net

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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 < syntax, but people are never sure whether they are <<"EOF" or <<`EOF`.


I am a "people" and I am very sure that < <<"EOF". And EOF is usually short for End-Of-File so why use it for a
string delimiter?



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;



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;
}



An arbitrary C-style loop can be replaced with a while loop with a
continue block.


For example?




John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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_fu nction=&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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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.00000002 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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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=3Dshift; as a
better alternative to $var=3D$_[n] - which it is - but it is a
(admittedly slight) performance hit vs ($var,$var2,...)=3D@_;


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 fr=
om
>> shell).
>
> FYI: =A0Actually, EOF dates all the way back to JCL. =A0The alternative i=
s EOD,
> End Of Data.
>
>
> --
> Just my 0.00000002 million dollars worth,
> =A0Shawn
>
> Programming is as much about organization and communication
> as it is about coding.
>
> The secret to great software: =A0Fail early & often.
>
> Eliminate software piracy: =A0use only FLOSS.
>
> --
> To unsubscribe, e-mail: beginners-unsubscribe@perl.org
> For additional commands, e-mail: beginners-help@perl.org
> http://learn.perl.org/
>
>
>

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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:
>=20
> Under "Subroutine Arguments Handling" you offer $var=3Dshift; as a
> better alternative to $var=3D$_[n] - which it is - but it is a
> (admittedly slight) performance hit vs ($var,$var2,...)=3D@_;
>=20

Well, one good use case for =ABmy $var =3D shift;=BB is this:

sub my_method
{
my $self =3D shift;

my ($arg1, $arg2, $arg3 ... ) =3D @_;

.
.
.
return $self->_other_method(@_);
}

In perl-5.10.0 before perl-5.10.1 came out, there was a significant slowdow=
n=20
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=
=20
performance hit is not significant.

>=20
> Otherwise, pretty useful info. I'm forwarding the link to the rest of
> my group. :-)
>=20

Thanks!

Regards,

Shlomi Fish

> Jonas Bull
>=20

=2D-=20
=2D--------------------------------------------------------- -------
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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: "Perl Elements to Avoid" Document on http://perl-begin.org/

On Oct 7, 3:07=A0pm, 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 "P=
erl
> 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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@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 =3D 0; $i < $n ; $i +=3D 2)
> {
>        print "$i\n";
> }
> [/code]
>
> into:
>
> [code]
> {
>        my $i =3D 0;
>
>        while ($i < $n)
>        {
>                print "$i\n";
>        }
>        continue
>        {
>                $i +=3D 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..


--=20
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software ..org>

--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

Re: "Perl Elements to Avoid" Document on http://perl-begin.org/

On Oct 10, 12:59=A0am, 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 w=
ith
> > > 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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/

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-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/