> Question #1: Does anyone have any favorite document
> that is a style guide for perl programmers? There are
> entire books on the subject of style for C++
> programmers, I've not seen any for perl, though.
>
Well there is the perlstyle doc page,
perldoc perlstyle
that gives general suggestions from the man himself.
> I'm in the unfortunate position of being a lone
> programmer on a Perl project. I've taught myself perl
> with the help of Wall's book and this mailing list and
> I've had to learn some pretty painful lessons. The
> code I've inherited has mostly taught me what NOT to
> do. (sigh).
>
That is unfortunate, often the best way to learn is with a mentor,
though it is more difficult to find them (us) in Perl than other
languages. I would suggest getting on the [EMAIL PROTECTED] list and
reading as much as possible, it is a very high traffic list but
generally the code discussed and posted there is of excellent quality,
and many of the responders really do an excellent job of teaching along
the way. The CGI list isn't really geared enough towards Perl itself
(as thats just not the primary purpose).
> Question #2: Is this bad style?
>
> my $q = new CGI;
> my ($v1, $v2, $v3) = ($q->param("arg1"),
> $q->param("arg2"), $q->param("arg3"));
>
Well your variables need better names, but I suspect you know that. I
wouldn't call it bad style, but to me if you have multiple params you
may want to just grab them in a hash from the start and not bother
wrangling individual variables. So
my %params = $q->Vars;
Should make it easy to access any parameter easily. See,
http://search.cpan.org/~lds/CGI.pm-3.04/CGI.pm#FETCHING_THE_PARAMETER_LIST_AS_A_HASH:
For more.
> I think so. If arg1 is missing, $v1 gets arg2. I hate
> that feature! It stinks! I'm inclined to abandon
> declaring multiple variables in a single statement as
> a matter of general principle. What is your opinion?
>
This seems odd to me, $v1 should be undefined or empty rather than have
the second parameter's value, having just tested it you are right and I
would avoid the syntax, it doesn't seem very Perlish to me... hmph. I
suspect Perl is calling the param method first, then collapsing the
list, then doing the assignment, which does make sense, but doesn't make
it terribly readable. My opinion would be to go the hash method, then
check for existence of the keys you need. If you must have single
variables then you can wrap the 'Vars' call in a hash slice to get the
values and guarantee that if one is missing the destination is assigned
undef instead.
> Question #3: How big should my modules be? I inherited
> 3000 line modules. I noticed I spend A LOT of time
> matching up braces in modules this large. Do I pay a
> performance penalty if I have dozens of different
> modules for a cgi program?
>
There is no set size. If you're matching up braces, then your problem
is more likely that the subroutines in the module are too long, not the
module itself. You may pay some performance penalty in loading them all
upfront but not much assuming you need all the code, the issue becomes
when there is lots of code to load that never gets called, which is what
autoloading is for. However this is typically only a problem on very
high traffic sites, or occasionally on high speed networks. In general
the perl interpreter is fast enough that the additional amount of time
to load the extra code is not seen because of network latency or other
factors. I wouldn't worry about code size until you know you have the
problem, or your application is complete and you can start to learn more
advanced techniques for delaying code interpretation, etc.
As a side note you may want to look into an editor that allows you to do
code folding, this will help you only look at sections of code you need
to and allow you to move around your code faster, skipping large
sections that are not currently under the knife. Vim and Emacs, two
very highly thought of editors, both have this functionality, I don't
know of others though I am sure they exist.
> Question #4: These statements terrify me:
> my @x = (1, 2, 3);
> $Case->{xyz} = [EMAIL PROTECTED];
> print $Case->{xxyz}[0]; # Typos!
>
I see you have found references, and are aware of how to use them, you
may not be as far behind as you let on, but you may want to check out:
perldoc perlreftut
perldoc perllol
perldoc perldsc
perldoc perlref
For some light reading on the subject...
> Is there anyway to get a syntax error when I type
> "xxyz" when I intended to type "xyz"? I don't believe
> "use warn" or "use strict" help me here.
>
Your print statement should be issuing a warning about an uninitialized
value, but to Perl it isn't really a syntax error, it is a runtime
error, so strict can't bail you out here. Excellent that you are using
these two pragmas, if the code you are working with does then it may not
be as bad as you think, or its just not as bad as it gets :-), trust me.
> Are hashes the only counterpart to C structs? It seems
> to me perl needs the struct feature that will give me
> a syntax error when I reference a field that does not
> exist.
Yes and no, it would be nice to have a way to check keys, but since they
are generated at runtime there is no real way to do it. As far as the
functionality of a struct, by using references you can build an
arbitrarily complicated structure within a hash. There are modules on
CPAN that will give you more of a feeling of a C struct, and may even
provide compile time errors for misuse. In general I have found as my
coding habits improve that I rarely have this problem.
>
> Question #5: I don't understand prototyping in perl.
> Will prototyping in Perl help detect syntax errors the
> same way protyping in C will help detect syntax
> errors?
>
For now don't bother with prototyping. There was recently (within last
month) a discussion of it on the beginners list if you want more info. I
have never needed it.
You mentioned Wall's book, which I assume is the Camel, which is an
excellent choice. It sounds like you are a C programmer, so the Llama
may be too quick of a read, but it is an excellent resource for picking
up good style tips, as well as discussions for some of the above topics.
It provides a foundation you can't get elsewhere. You may also want
to check out the Llama's extension, the Learning Objects, References,
and Modules book.
> Thanks for all your help!
> siegfried
>
Come back with more questions, specifically CGI ones, again I highly
suggest the plain beginners list for basic (and not so basic) Perl
questions not of a CGI nature....
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
