Re: Parsing the command line: manual or module?

Before I wrote my code in Perl, I was a C programmer. One of the first C applications that I wrote started off as a prototype, and as often happens, the prototype became the working piece of Production code.

One of the routines started out with a few parameters, then grew, finally needing eight or ten parameters. Every time I'd add another, I'd think, "Gee, this is getting really unwieldy".

Well, that's hindsight.

In C, you have no choice but to pass in a long list of parameters .. but in Perl, there's no need to cripple your code with that kind of limitation. As soon as a function requires more than two or three paramters, make them an arg hash. If it's the comman line arguments, use Getopt::Long.

The risks of not using a module are that you'll reinvent your own wheel. This is not a bad thing, except that your solution isn't going to have the attention paid to it that the equivalent module did, and it'll take longer.

That could pay off in the long run, but it might lead to difficult discussions with your manager about why the three week development schedule has expanded out to eight months. Part of being a Senior Developer is knowing when to write it yourself, and when to use something that someone else has written.

Let CPAN make you look good today.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Comment on Re: Parsing the command line: manual or module?

Replies are listed 'Best First'.
Re^2: Parsing the command line: manual or module? by Fletch (Bishop) on Aug 17, 2006 at 19:26 UTC
I want to say there's a refactoring (from the book of the same name) that is recommended for when a routine starts getting too many parameters. I want to say something along the lines of encapsulating some (or all) of the arguments into an object, and/or possibly moving the behavior onto that object so the current implementer becomes a client using an instance of the new class. (Unfortunately I don't have my copy at hand, but someone may chime in that actually remembers it or does have a copy nearby . . .) Update: Found it: Introduce Parameter Object, p295. The (simple) example given is a series of calls which all take a start and end `Date`; the refactoring is to create a `DateRange` class which encapsulates both.	[reply]
Re^2: Parsing the command line: manual or module? by djp (Hermit) on Aug 18, 2006 at 03:11 UTC
You can pass mutiple arguments via a struct in C in just the same way you use an arg hash in Perl. You can use getopt(3C) in C in just the same way you use Getopt::Long in Perl. Similar techniques exist for other languages.	[reply]
Re^3: Parsing the command line: manual or module? by talexb (Chancellor) on Aug 18, 2006 at 03:21 UTC
Yeah, I know that -- but every time you want to add a parameter you have to modify the struct definition and do a make, so it's not a simple thing to do. I didn't want to confuse the post with that situation. In Perl, if you want to add something to an arg hash, the caller and the callee need to be modified; no one else cares, and that's the way it should be. I deleted a paragraph from my original post that talked about how I wrote a device independent video graphics module for two graphics cards (heh), CGA (if you can call 640x400 useful) and Hercules (720x348 or something like that -- ok, wikipedia says it was 720x350, close enough). To use these two cards, I would call a subsystem with ~~function pointers for~~ pointers to each of a dozen ~~function pointers~~ functions, when obviously a pointer to a structure containing function pointers would have been way more efficient way to implement that. Like I said, it was my first big project. My coding standards have improved immensely since then -- hey, I discovered `make` back then and thought it was a pretty advanced tool. It was only later that I discovered it had been ported from Unix. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds Updated Sunday August 20, 2006 at 1222 After re-reading, realized that my purple prose needed a little clarification. Old is struck through, new is in italics.	[reply] [d/l]