User since: Mar 23, 2008 at 17:25 UTC (16 years ago)
Last here: Jul 09, 2024 at 07:15 UTC (2 weeks ago)
Experience: 5770
Level:Vicar (15)
Writeups: 885
Location:New Zealand
User's localtime: Jul 21, 2024 at 20:19 NZST
Scratchpad: View
For this user:Search nodes

Just a person who appreciates Perl.

Some things to keep in mind

I know just enough to be dangerous and don't know what I don't know.

Get help from others and don't reinvent the wheel, except as an intentional learning exercise. Peer reviews are a great way to learn, get help and help others.

Find and follow "best practice" advice, but not dogmatically.

Learn and think carefully about your options, be clear about your needs and objectives, consider both long and short term issues and then choose what you think is the best option in the circumstances. There is always conflict and tension between various needs and objectives (e.g. we need it to be ready yesterday and we need it to be very fast and we need it to do everything and we need it to be easy to maintain and we need it to be formatted by perltidy (all defaults) and we need the format to be consistent with the legacy code base and we need the comments to be optimized for both junior and senior programmers/developers, etc.).

TEST!! I make mistakes whether I test or not but at least if I test well I can find and fix them before they cause too much harm (and make a fool of me). YMMV.

Posting on PerlMonks

Other than the Chatter Box, posts to Perl Monks will be here for a long time (one hopes Perl Monks will be here a long time). It will be a better place if the posts have good long term value, as well as meeting immediate needs. sundialsvc4 has some suggestiongs for long term value.

Getting Help

[id://174051] How do I post a question effectively?



how to begin with testing?

Does anybody write tests first?

Testing IS Development

What is the best way to compare profiling results before and after a code change?

Unit testing of C source code

Testing methodology, best practices and a pig in a hut.

Solving the Problems

[id://376075] brian's Guide to Solving Any Perl Problem

[id://745674] Basic debugging checklist

Re: $obj->method v.s. $obj->method() presents some of the options for finding out what your program means to perl.

Perl Programming

There are many excellent resources identified in Getting Started with Perl and perhaps a few more in Perl documentation documentation. Learning the rudiments well is a prerequisite to writing good programs and to learning more advanced aspects of programming.

The book Perl Best Practices has some excellent advice but before getting carried away you should also read Perl best practices fanatism and Perl Best Practices and realize that there are many variations on "best".

Perl::Tidy is a nice and flexible tool that can help you improve the formatting style of your programs. In the end, you will have good reasons for ignoring its decisions at times (it is, after all, a simple program with limited rules and heuristics for deciding what layout is best). Until you know why you want your code to be different, it may be best to format it as perltidy does.

Perl::Critic is another quite flexible tool that can help you identify aspects of your program which might be less than ideal. It covers much of the guidance in Perl Best Practices.

On commenting code: Why no comments?, Re (tilly) 2 (disagree): Another commenting question,

On globals: Are global variables "bad"? Global variable vs passing variable from sub to sub

Module version numbers: module version numbers

Administering Perl

Install Perl Locally -- If this works for Catalyst, it'll work for anything!

What is the best way to install CPAN modules on Debian?

Installing a perl with a minimal, collapsed directory layout