open_file is not really just opening the file, it is grabbing the contents of the file; You might want to make the name of the sub match the action of the sub more closely.
I would not declare the my @contents outside the sub and then rely on the side effect of the sub altering the data in contents. Instead I would pass the @contents into the sub by reference, and have it filled that way. This avoids creating two different arrays and copying them around via pass-by-value.
Side effects can be confusing when code gets reused later. For instance this code snippet is only useful if you want to fill a previously existing array named contents -- not very modular.
It also might be useful for the calling routine to be able to tell if an error occurred during the "grabbing"; Passing back an error code would allow the caller to gracefully recover from any possible error. I believe it is better to allow the caller to recover from the error rather than the "grabber" because any number of callers may want to react in a different way, so returning the code allows that -- reacting with the die inside the "grabber" does not. Returning a '0' can signify no error occured.
my @contents; my $error = grabFile('myfile.txt', \@contents); sub grabFile { open(FILE, $_[0]) || return ($!); @{$_[1]} = <FILE>; close(FILE); return 0; }
And this is not OOP.... OOP is much more than this.
In reply to Re: Re: Modular Code
by Sifmole
in thread Modular Code
by Stamp_Guy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |