Laufeyjarson writes…

The PBP suggests using a module called Sort::Maker to build powerful sort functions without getting hung up in the details and possibly messing up the implementation. (more…)

The Best Practices suggest avoiding string eval. (more…)

The Best Practices suggest using CPAN modules for more complex data parsing, instead of trying to roll your own. (more…)

The Book suggests using split to take apart separated data with simple separators. (more…)

The PBP suggests we use unpack to take apart fixed-width data. (more…)

The PBP suggests that when you want to reverse a scalar, you explicitly state this with ‘scalar reverse $variable’ instead of just using reverse on it.  It suggests this both makes explicit, and regularizes the use, regardless of the context it is called in.

I don’t like this suggestion and don’t feel it is needed, but I won’t object to it because of the clear example in the book that makes it clear how it helps.  I find the demand you add a ‘scalar’ all the time because sometimes it’s unclear to be a problem.  I’ll probably turn off the critic warning for this, but I won’t say it’s too horrible.

Mr. Conway suggets using the reverse builtin when appropriate.  This includes with sort, and for counting backwards. (more…)

The Best Practices have things to say about many of Perl’s built-in functions.  Besides the general advice “use them” – which I agree with – it has some specific suggestions.  First up: Sorting (more…)

It is a Best Practice to check the spelling, syntax, and sanity of your documentation.  I agree with this, strongly. (more…)

The PBP suggests a way to put longer blocks of documentation in code, by using the =for or =begin/=end notation in POD.  By labeling these with a “formatter” that does not exist, they’ll never be output and are merely ignored by the compiler and for the author’s use. (more…)