Re^2: Does the size of a variable's name affect memory?

Not to be rude, but no matter how large your program is getting, you have a design problem if you are having to use 30-50 character-length descriptive names for variables and subroutines. I'd go back and fix things up a bit. I have never come across a valid reason for needing to go past 20 characters per item. By using these ridiculously long identifiers, you are creating a maintenance nightmare; nobody else will even want to look at your code, never mind having to actually update the code.

# 49 characters? my deity, what could possibly be wrong
# with this horrid picture?
my $path_to_configuartion_file_for_apache_http_server = '/etc/httpd/co
+nf/httpd.conf';

# 37 characters. just as bad as the 49 charaters above.
sub get_the_path_for_apache_configuration {
    return "who cares?";
}
[download]

Comment on Re^2: Does the size of a variable's name affect memory? Download Code

Replies are listed 'Best First'.
Re^3: Does the size of a variable's name affect memory? by tilly (Archbishop) on Feb 17, 2005 at 19:57 UTC
Was the typo demonstrating the maintainance nightmare intentional or not? Either way it effectively made the point. :-)	[reply]
Re^3: Does the size of a variable's name affect memory? by nmerriweather (Friar) on Feb 19, 2005 at 04:24 UTC
in terms of variable names, every perl book or tutorial i've read has said that hashes take up more memory and are slower to access than scalers. If thats not the case, than great -- but i've been under the assumption that $FRUITS__apples is faster to access and takes less memory than $FRUITS{'oranges'}. in terms of functions -- call me crazy, but i think that &get_the_path_for_apache_configuration() is a great function name. sure, i could have a class ApacheConfiguration, and setConfFilePath($path) getConfFilePath() -- but why not have a name like that and save myself an object creation? I'm not being sarcastic - i tend to come off like that, so please don't misread me. I want to code legibly, and efficiently, and am open to many ideas.	[reply]