Perl like it’s for CPAN?

Why don’t I write more technical content? I spend so much of my time writing and researching code and code related things. After reading through some tips I think I’m going to try and make a more concerted effort to post some more technical and hopefully useful content.

Perl Buzz has a short extract from Chris Prather’s blog coding all your code like it should be for CPAN. In particular he mentions building make files so that you can automatically install dependencies using CPAN. Whilst I’m not entirely sure the merits of using make files for all your code are completely valid, the other stipulations that CPAN have in place certainly have proven useful to me.

Perldoc: Anyone not including proper documentation in their Perl modules really should do. Even if you ‘think’ noone else will ever work on your code. So many times I’ve come across some code that has no documentation and had to struggle through it. Now that’s a pain when it’s someone elses code, but it’s embarrassing when it’s my own!

Commenting: There is a big difference in my eyes between standard commenting and Perldoc. Perldoc is great for documentation relating to your modules. What your module does, what functionality it offers, who wrote it etc. Commenting however is to explain what you are doing with your code. All Perl developers are guilty of writing slightly less than readable code at one time or another. The more commenting you use the easier it becomes to follow the code. There is nothing worse than having to come back to your own code and not being able to fathem it out quickly.

Version Numbers: Version numbers are a requirement for all modules on CPAN. As I use version control for all my modules I have version numbers associated with them. I don’t include them in the modules unless they are to be distributed. Nevertheless being able to differentiate between instances of the same module is important.

Testing: All modules require unit tests. Unit testing is something I’ve recently learned to embrace. If you are of the mind set that writing tests takes too much time. Then I’m sorry you are simply wrong. Every time you write some code for a project you can quickly run the all the tests on all the modules in that project and you know that everything should work. As you need to check if your code works anyway you need to test it, if you don’t do this by writing tests you do it using some other process. Querying your web server for example. Firing you your web server takes time, requires resources and may not be a good for other people who want to use your module.

Well that felt like a bit of a rant but I feel that some of this stuff is fairly crucial to Perl developers and know that it’s the way things are tending towards at work.