in reply to Does the size of a variable's name affect memory?

ah - i knew that perl stored things in a global table, i just wan't sure if any some or no 'optimization' of variable names took place, like in a compiled language

i like to use highly semantic naming conventions for my functions, and often vars -- so i often have 30-40 character names.

the current project i'm working on is getting quite large, and more functions mean more descriptive names, so i'm looking at pushing 50char names.

easily readble and understandable code is #1 for me, so i'm just glad that the tradeoff is almost non-existant in terms of memory use.
  • Comment on Re: Does the size of a variable's name affect memory?

Replies are listed 'Best First'.
Re^2: Does the size of a variable's name affect memory?
by gaal (Parson) on Feb 17, 2005 at 05:44 UTC
    > easily readble and understandable code is #1 for me

    Do you know about namespaces? Do you make effective use of complex data structures? Do you avoid using a set of scalars when a single hash would do (and do better)?

    Extremely long names in Perl *may* be an indication these areas need more exploration.

Re^2: Does the size of a variable's name affect memory?
by saskaqueer (Friar) on Feb 17, 2005 at 08:36 UTC

    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?"; }
      Was the typo demonstrating the maintainance nightmare intentional or not?

      Either way it effectively made the point. :-)

      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.