|
|
|
| laziness, impatience, and hubris | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Personally, I don't use constants. However, I work on a relatively large project with over 1000 files. That means that hiding my globals in modules that inherit Exporter tends to be more efficient for me. (And, easier to maintain, to boot!)
That said, by using use constant, you are being purer, in a sense. You're giving more information to the reader of your code as to exactly what's going to happen in the rest of the code. This is a good thing. That said ... unless you are absolutely positive about the lifetime scope of what you're working on, I'd tend to shy away from constants. Let's say you're working on something that takes information from a number of Perl modules (like parent, children, function names, etc) and makes a bunch of HTML pages from it. Initially, you're going to be working with a small set of files, so making a bunch of stuff constant, like the base directory, makes sense. However, your project grows. You start to realize that you want to allow for greater flexibility. Maybe you don't think that you can change the constants, so your development possibilities are restricted. This sounds far-fetched, but it really isn't. I conceive of constants as things that can never change, no matter how my script/tool/app changes. Things like PI, E, etc. I don't care what happens to what I've written, but PI isn't changing. That's a good choice for a constant. Making a filename a constant means that you have to alter your code significantly if you want to allow users to pass the filename into the script. That's a design that wasn't thinking ahead. Just my $0.02. In reply to Re: my $var; vs. use constant VAR = '';
by satchboost
|
|