Re: On bad habits
by jhourcle (Prior) on Jun 21, 2005 at 10:31 UTC
|
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.
| [reply] |
Re: On bad habits
by tlm (Prior) on Jun 21, 2005 at 12:59 UTC
|
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.
| [reply] |
|
| [reply] [d/l] |
|
| [reply] |
|
|
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.
| [reply] |
|
Re: On bad habits
by PhilHibbs (Hermit) on Jun 21, 2005 at 10:49 UTC
|
I parse XML with regular expressions.
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. | [reply] |
Re: On bad habits
by cosimo (Hermit) on Jun 21, 2005 at 11:36 UTC
|
> Excessive use of double quote interpolation - I'm really
> doing myself no favours with print "$variable"; but I use
> print "$variable\n"; very heavily so the " gets to be a
> reflex, even where I'm not using \n.
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;
> 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.
Just my € 0.02
| [reply] [d/l] [select] |
|
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.
| [reply] |
|
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_
The underscore after EOT indicates a trailing space which can help a lot in this case.
Arjen
All that is gold does not glitter...
| [reply] [d/l] [select] |
|
|
If I am going to use newline frequently, I create a constant for it.
use constant NEWLINE => "\n";
print $foobar . NEWLINE;
---
The harder I work, the luckier I get.
| [reply] [d/l] |
|
#!/usr/bin/perl -l
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. ;)
| [reply] [d/l] |
|
|
|
|
| [reply] [d/l] |
Re: On bad habits
by grinder (Bishop) on Jun 21, 2005 at 11:38 UTC
|
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.
• another intruder with the mooring in the heart of the Perl
| [reply] |
Re: On bad habits
by wazoox (Prior) on Jun 21, 2005 at 12:14 UTC
|
Using quoted strings where print <<END_BLOCK would make it clearer.
This one isn't that bad. Here docs are sometimes evil too, because they force you to break your nice, clean indentation. Think qq() instead...
| [reply] [d/l] |
Re: On bad habits
by perrin (Chancellor) on Jun 21, 2005 at 17:10 UTC
|
I confess -- I think about performance too much and optimize too soon. It's fun, but counter-productive. | [reply] |
Re: On bad habits
by samtregar (Abbot) on Jun 21, 2005 at 17:26 UTC
|
I jump to invent my own solution even when adapting an existing one is a better choice. I'd rather write new code than patch old code and that preference sometimes gets in the way of finding the simplest thing that will work.
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
| [reply] |
|
My bad habit is never getting in the habit of writing tests at all. :)
| [reply] |
|
| [reply] |
Re: On bad habits
by poqui (Deacon) on Jun 21, 2005 at 19:40 UTC
|
My favorite is
- Do it the hard/long way first.
That means that if there is an easy shortcut, I will steadfastly ignore it until I've done it the hard way. However, I think I get more understanding of the solution if its a new one for me.
| [reply] |
Re: On bad habits
by trammell (Priest) on Jun 21, 2005 at 14:33 UTC
|
These days I find myself using the "-l" perl option a lot, and I rarely need to put explicit "\n"'s in my code (maybe for printf). A nice bit of laziness/DWIMery. Perhaps that would help you break your habit.
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. | [reply] |
|
| [reply] |
|
How does use of -l affect modules which aren't expecting it? The docs indicate that they will double-space anything they print.
| [reply] [d/l] [select] |
Re: On bad habits
by gawatkins (Monsignor) on Jun 21, 2005 at 14:29 UTC
|
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.
Thanks,
Greg W
| [reply] |
Re: On bad habits
by 5mi11er (Deacon) on Jun 21, 2005 at 16:24 UTC
|
Not using strict or warnings when I first start to throw something together. Then after working on it a few days, spending half a day cleaning it up when I finally remember to put those in.
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 | [reply] |
|
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.
| [reply] |
Re: On bad habits
by DrHyde (Prior) on Jun 22, 2005 at 07:26 UTC
|
I hate heredocs. They break your indentation.
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 ;-) | [reply] [d/l] [select] |
|
| [reply] |
Re: On bad habits
by GrandFather (Saint) on Jun 22, 2005 at 00:55 UTC
|
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.
Perl is Huffman encoded by design.
| [reply] |
Re: On bad habits
by artist (Parson) on Jun 22, 2005 at 08:58 UTC
|
I go an extra mile about inventing and implementing software engineering solutions, and then realize later that bug-fixes takes all the time.
| [reply] |
Re: On bad habits
by TedPride (Priest) on Jun 22, 2005 at 01:35 UTC
|
Join and split are sexy, but I rarely use map. It doesn't offer that much in the way of speed difference vs for (which, btw, can be the same as foreach in Perl, only shorter to write), and it makes your code much more complicated to read. There's something so beautiful about being able to do:
@arr = qw/aaa aba abb bac efg/;
tr/a/x/ for @arr;
print join ' ', @arr;
perrin: What's the point of having $_ and @_ if you don't use them? I will agree that any reasonably large sub should define variables for the contents of @_, but it's just so much neater to do a series of regexes on $_ than on a variable. I use it as much as possible. | [reply] [d/l] |
|
| [reply] |
Re: On bad habits
by jordanh (Chaplain) on Jun 22, 2005 at 20:07 UTC
|
my ($data) =~ /^DQ(....)\d*.DAT/
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. | [reply] [d/l] |
Re: On bad habits
by arc_of_descent (Hermit) on Jun 26, 2005 at 05:03 UTC
|
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.
| [reply] |