In general you should aim to localise the understanding of the code to the current context. By that I mean, the bit of code you are looking at now should be written so its purpose is clear without having to refer to other materials.

Generally that means rewriting something like:

setOptions (1, 0, 'e');
[download]

as:

setOptions (send_log => 1, suppress_warnings => 0, max_level => 'e');
[download]

A little more verbose, but now (even without the context) it's pretty clear what the parameters do and what setOption is likely to achieve.

Or to paraphrase a great man: make your code as clear as possible, but no clearer :).

That's my opinion. Even if the function is simple, I still wouldn't copy it over and over, because I believe it's a distraction from the rest of the code. If you're going to go this way, stuff the function in in a module called OurCompany::FixedLengthUtils or something, and then no one has to think about how it works, they can just use it, or look up the docs for it.

And, I would probably create a separate module/class for each format especially if you'll be reusing the same formats in different scripts (which Parse-FixedLength has instructions on doing -- disclaimer: I'm the author :-)

Parse-FixedLength is a really nice module, and was the leading contender among the three modules when I first went looking. Nice job.

I couldn't tell from the docs if it accepted the "=>" form when using the pack/unpack format specs. We have binary data to read, and I want the name and format columns to line up, so using a ":" separator in a single parameter would have been a problem. With your encouragement I've tested the "=>" and it works fine. It also works in 5.6.1, which is important for us.

I'll put together an example to present to the group at work, and I'm guessing we'll use Parse-FixedLength. Thanks.

Another thing I like to do when creating a separate class/module for different formats is to add pod to the module to document the details of the format and what the fields are (and their start/end position and length). Then the documentation for the format is just a 'perldoc Something::SomeXFormat' away (and I don't have to hunt for the hardcopy I worked from to create the module) :-)

Update: What would be nice is if the code defining the format was actually read from the pod (or vice-versa), so the docs would be self-updating...but I'm not sure about the best way to do that at the moment.