Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

keywords versus variables

by rvosa (Curate)
on Aug 30, 2007 at 15:28 UTC ( #636114=perlmeditation: print w/ replies, xml ) Need Help??

Dear monks,

a quick observation: I have a sense that, the fewer variables I use relative to keywords and operators, the better. I.e. my code seems to be less buggy and more elegant if there are few temporary scaffolding variables (loop counters and so on), hardcoded class names, complicated data structure dereferencing and method calls (in order of decreasing egregiousness). It's easy to see code quality by the colors in my editor :-)

Makes sense?

Comment on keywords versus variables
Re: keywords versus variables
by BrowserUk (Pope) on Aug 30, 2007 at 15:53 UTC
Re: keywords versus variables
by mr_mischief (Monsignor) on Aug 30, 2007 at 17:00 UTC

    It makes great sense that a program with fewer values to consider would have fewer bugs. Are you talking about two different programs where one has fewer variables by its nature, or are you talking about removing variables consciously from existing programs?

    The complicated data structures you mention I've always found handy for decreasing the overall number of variables, BTW. Instead of having a lot of related but disconnected variables that need to be passed around, I can have one data structure that describes a bunch of details about the current topic. I can then delete, alter, pass, and return the one data structure.

    Let's look at a typical first-year programming class assignment. I think most of us have done a very simple payroll program. Just the function call illustrates the point:

    figure_pay ( $name, $emp_id, $rate, $hours, $gets_overtime, $hours_without_ot, $ot_multi );
    vs.
    figure_pay ( \%employee );
    So all other things being equal, I'd say you're definitely on to something. I think perhaps it's balanced against other issues, though, and shouldn't necessarily be a singular goal.
      I think perhaps it's balanced against other issues, though, and shouldn't necessarily be a singular goal.
      Oh, definitely. It's a bit of a silly "metric", of course. My point about the complex data structures was that, if you have to do
      $blah->{something}->{and_deeper}->[12]
      you'll be pretty bug prone and so you might consider refactoring into something like
      $deeper->item(12)
      ...which is why I put method calls on one lower level of egregiousness :)
        Good point. Even if you are doing the former on some level, hiding it behind the latter for most code should still help cut down on bugs. Doing the complex one in one place and the simple one in lots of other places could be quite a maintenance win.

      perhaps even better:

      $employee->figure_pay ();

      or:

      $employer->figure_pay ($employee);

      DWIM is Perl's answer to Gödel
        definitely even better:
        $employee->figure_raise();
        or:
        $employer->figure_really_sweet_bonus($employee);
        Especially if you're a company like ADC that runs payrolls for a living.
Re: keywords versus variables
by Gavin (Canon) on Aug 30, 2007 at 17:06 UTC
    Less chance for spelling and copy and paste errors too if variable names are kept simple.
      True, but maintenance gets hard when they aren't evocative.
        but maintenance gets hard when they aren't evocative.

        Not so.

        Did you ever see music annotated with: "This_is_the_second_demi_semi_quavar_in_the_third_bar_of_fifth_stanza" (*).

        Or a resistor on a circuit diagram annotated: "This_is_the_470_ohmm_resistor_that_impedance_matches_the_output_of_the_third_stage_amplification_to_the_fourth_stage_feed_back_loop". (**)

        (*)I've no idea if that makes sense, but a musician would.

        (**)Ditto; but an electronics engineer would.

        Short variable names in context are just as clear to the maintanence programmer, and often more so, than long, overly descriptive ones--if the programmer has familiarised themselves with the purpose of the routine of which they are a part.

        And if he hasn't, he should not be maintaining the code.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: keywords versus variables
by ambrus (Abbot) on Aug 30, 2007 at 21:24 UTC

    I think it's quite the contrary. If you use abstractions, factor common parts of code to subroutines etc, you'll have more variable names and less keywords, and probably better code. It depends of course, such simple rules should not be taken to the extreme.

Re: keywords versus variables
by papidave (Monk) on Sep 08, 2007 at 16:21 UTC
    I'm afraid I have to vote with ambrus on this one, for most cases. The problem, as I see it, isn't the number of variables, but the distance between the definition of those variables and the location(s) where they are used. In addition to the OOP methods mentioned above, declaring your my variables in a short scope can go a long way towards improving readability.

    The most obvious case would be the replacement of a single global variable with a scope-restricted variable and access methods for it. IMHO, this would be an improvement even if the code that uses those access methods needs additional temporary vars to work with it.

    That said, I do favor refactoring code to reduce the number of variables passed into a function, or the number of levels through which an argument is passed before it gets used.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://636114]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (16)
As of 2014-09-02 20:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (29 votes), past polls