You might be interested in the Stupid mistakes I repeatedly make thread

Update:: The comment above wasn't intended to necessarily be a replacement for this topic, but as something similar, right before I left for work this morning.

I'd say that my worst habit, that qualifies more as a 'bad habit', as opposed to what I think of in the context of the other thread, is trying to fix things -- I'll be browsing through code that I wrote years ago, and think to myself 'well, that's a pretty stupid way to do things ... I know of much better ways now', and then modify something. Of course, after it's been working error free for years, I'll end up breaking something, all for the sake of making it 'more maintainable', when it didn't need to be maintained (as it was working, before I screwed with it), or to shave off a few milliseconds, when it didn't need that, either.

Of course, this bad habit was indirectly covered by cog in his comment in the Never, never, never thread.

By far, my single worst habit is making my code too terse. Typically I realize it only weeks later when I find myself needing to decipher it. When I first write it never seems too difficult to understand; this apparent legibility is an artifact, of course, but I have a hard time distinguishing it from the real thing. I'm not entirely cured of this bad habit, but at least I am aware of it.

My second worst habit is being too enamored of the whiz-bang features, the challenging syntax acrobatics, and the cool puzzles hidden in practically every programming task, which easily leads me to miss the best solutions when these happen to be boring. Again, I'm very aware of this, but in this case a cure is not even in sight.

Funny, I'm just the opposite. I make my code too lengthy and comment too much.

I used to have the bad habit of while (chomp(my $line = <INPUT>)) but a few gasps from some monks cured me of that. Amazing what even minimal peer review can do for coding practices.

But just to clarify, the biggest problem with that code fragment is not that it's lengthy, but that it discards the last line of the file when it does not end in a $/.

the lowliest monk

Verbose is fine, if it's clear and easy to read. Don't let people tell you that you must use $_ just because it's there.

I have a number of state machine scripts that process XML files that are exported from the DataStage data migration tool. The file format is pretty predictable in terms of line ends and layout, so the scripts work in the limited context that they are written for.

I must admit I also have this "weakness", although I happen to prefer:

    print $var, "\n";
    # but...
    print "$var\n" for @list;
    # or...
    print($var, "\n") for @list;
[download]

> Excessive use of foreach, where join or map would be preferable

You can eliminate this bad habit just by using for instead of foreach :-)

> Excessive use of eval. I've just about cured myself of
> that, since I found out how slow it is.

I don't think eval is slow. Eval'ing a string is slow, because IIRC it spawns a "new" interpreter, but eval'ing a block is ok.

> Using / as a regex separator, when the regex would be
> clearer with an alternative.

Yes, I'm also with you on this one, though at times I use the pipe char (|) instead of /.

> Using quoted strings where print <<END_BLOCK
> would make it clearer.

I'm with you here. Sometimes I don't "feel" using here docs, even if <<'       END_OF_TEXT' allows for clean indented blocks.

eval STRING does not spawn a new interpreter. It makes a call to the compiler to parse and compile the string. Then it executes it and throws away the newly compiled code.

Here-docs are a cause of a class of error you can only avoid by avoiding here-docs. Lest that sound dumb to you, try adding a space to the end of your here-doc tag in the <<TAG start or in the TAG end. Both are usually invisible and both will cause your script's parsing to be completely awry. They're just a great way to shoot yourself in the foot.

This is where your editor can help. Emacs' cperl-mode can display trailing whitespace. For example:

print <<"EOT";
This is
a piece
of text.
EOT_
[download]

The underscore after EOT indicates a trailing space which can help a lot in this case.

Arjen

All that is gold does not glitter...

If I am going to use newline frequently, I create a constant for it.

use constant NEWLINE => "\n";

print $foobar . NEWLINE;
[download]

--- The harder I work, the luckier I get.

No thanks. :) If i am going to use a newline frequently, i add the -l (dash elle) run switch:

#!/usr/bin/perl -l
[download]

And then i don't need to worry about adding newlines. Uh oh ... what if i don't want to always print out a newline? Simple, just use printf.

Work smart ... not hard. ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Alternatively, remember that unless you changed it for slurp mode or whatnot, $/ is a newline.

I have to stop running CPANPLUS as root. It's one of its most salient features (update: that you can run "make" and "make test" as a regular user, saving root for only the "make install" part), and yet each time I set it up on a machine I do so as root, rather than fiddling about with sudo(1)

Definitely the Wrong Sort of Laziness.

Using quoted strings where print <<END_BLOCK would make it clearer.

I don't do as much test-driven development as I should. I almost always write tests but sometimes I write them after the code is mostly working.

-sam

My bad habit is never getting in the habit of writing tests at all. :)

Oh, I think you'll be breaking that one real soon.

(Aside to the audience - friedo just took a job working with me at Plus Three).

-sam

• Do it the hard/long way first.

Update: Thanks, !1, I didn't know that, but it makes abundant sense. I suppose I've never run into it before because I don't use a lot of modules that have their own file IO.

Use it only if you aren't using modules which are expected to manipulate files. I learned this the hard way when I wrote a throwaway script that used Archive::Zip and couldn't figure out why it wouldn't create a valid zip.

How does use of -l affect modules which aren't expecting it? The docs indicate that they will double-space anything they print.

I never take time to write comments-mostly because it is obvious what the code is doing...at least it is at the time I am writing it.

Spending more time here than coding.

Using terse variable names that I can't remember what they meant after a month, and forgetting to add a comment that would remind me.

I'm also guilty of not enough comments around the difficult to read stuff.

Not having enough fortitude to get the last bits done so I would think that a project is FINISHED. But, part of this is the shifting demands about what is important at the time. Something "important" always crops up toward the end of a cycle, and after working on that for a while it's tough to go back to get the previous project done. It works, but definitely needs some polishing...

-Scott

I always start my Perl scripts with a template file that has the "use warnings" and "use strict" already in it. Since I am working on Windows, it also has a variant on the bat2pl wrapper in place as well.

And I probably have the opposite bad habit to you with regards to map/join/grep instead of foreach - I should use foreach more. With foreach, your code reads from top left to bottom right, but with map and grep your code keeps changing direction and can sometimes be harder to read.

Incidentally, this whole thread - and the many others like it that we have had in the past here in the monastery - smack of Mao-ist self-criticism ;-)

>I hate heredocs. They break your indentation.

The Perl Cookbook has a hack for that.

--- The harder I work, the luckier I get.

I come from a C++ background so a lot of my Perl looks rather cish. However I really like modifiers and am learning about things like map, join and split.

On the other hand I really like hashes and am becoming a power regex user so that imparts a rather more Perlish flavour to my code.

@arr = qw/aaa aba abb bac efg/;
tr/a/x/ for @arr;
print join ' ', @arr;
[download]

What makes you think that everything in Perl needs to be used? I doubt anyone would claim that all of the ideas in Perl worked out equally well. Some are almost totally unused at this point.

Perl lets you choose what to optimize for. I choose to optimize for readability.

I've been doing this one a lot lately. Anybody else get bitten by this one?

my ($data) =~ /^DQ(....)\d*.DAT/
[download]

I stare and stare at it wondering why Perl is telling me that I have an uninitialized value in a pattern match when I _know_ that $_ has something in it.

I start coding before preparing any documentation. Although i do seem to have thought out the basic framework in my mind. But no, I don't want to write that down.

I also need to learn test-based development.

The above are not bad habits, just stupid ones I guess.