[JOB] Perl Software Developer and Database programmer

[Peter Hickman]

Andy Armstrong wrote:
> I'm not completely opposed to that. Again it depends hugely on the 
> context - but wrapping even a tiny bit of code like that in a 
> descriptive name can - in some circumstances - have value as 
> documentation. For example I've just written
>
> sub feed_name {
>     return show_name(@_);
> }
>
> Which makes perfect sense to me - at the moment the name of a feed is 
> the same as the name of a show - but that might change. This way, if 
> it does change, I don't have to go looking at all the instances of 
> show_name() to find out which of them should actually do something 
> different to get the name of a feed.
>
> --Andy Armstrong, hexten.net
>
>

Depends, if you were using it as

my $name_of_feed = feed_name(@list_of_names);

then I would say that it was wrong but if you are using it to add some 
semantic information to the code as in

validate(feed_name(@list_of_names))

then it would be right. The first tells you nothing that the receiving 
variable name does not and the fact that you have written a subroutine 
to do this might lead people to think that feed_name() is actually doing 
something important. The second tells you something that is not readily 
apparent, but of course a comment would also do the job.

How would you feel if you came across code littered with routines like 
add_two_numbers(), append_item_to_list(), check_hash_key_is_defined() 
and the like. Too much syntactic sugar for my liking.