Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
scooterm coding tips: The Principle of Parameter Parsimony

This coding tip is intended to demonstrate the Principle of Parameter Parsimony. It basically means this:

You should be as stingy and as sparing as possible when adding new parameters to your scripts, database schemas and application designs. The goal is to minimize the number of ways your application can go wrong.

To illustrate this principle, here are two straightforward examples:

Example1: Assign multiple scalars the same value

This example deals with the simple scenario of assigning the same value to more than one scalar. This node shows an interesting way to do it. This node explains why the previous interesting way can cause problems. The problem comes from violating the Principle of Parameter Parsimony.

### This is nice and compact, but what happens if you ### add new variables? You have to remember to keep count. ### You are essentially saying the same thing in two ### different places, and in two different ways. my ($a, $b, $c) = ('TRUE') x 3; ### A more parsimonious example my $a = my $b = my $c = 'TRUE';

We see from Example1 that we introduce problems when we aren't stingy with the way we arrange parameters in our code. The goal is to *avoid* saying the same thing in more than one place, and in more than one way.

Example2: Superfluous 'Status Flags'

Example2 deals with a more 'real world' scenario. Consider the following data structure that is based on a user database for a popular website.

my $User = {}; $User->{never_used_site_before} = '1'; $User->{fname} = ''; $User->{lname} = ''; $User->{password} = ''; $User->{age} = '0';

The basic strategy behind this data structure is to automatically consider a user 'new' if she has never used the site before. New users start with blank information. Afterwards, the 'never_used_this_site_before' flag is set to '0' when the user first signs on to setup an account on the "New User" page.

Seems harmless enough, right? Wrong! This is another example of non-parsimonious parameterization!

The problem is this. What happens if the user starts to sign on under the "New User" page, but then goes on a lunch break after filling in the fname field, and then leaves for lunch leaving some of the information blank? Suppose there is a session timeout? The never_used_this_site_before flag is turned to '0', but the user still has not filled in all the required information!

Based on this scenario, when the user comes back to log on to the site, it will tell her the password is blank, assume she is a new user and needs to create an account. When she goes to create an account, however, it will tell her that an account with that name *already exists* because fname and never_used_this_site_before have been initialized.

A more parsimonious way to do what we want is to *get rid* of the never_used_this_site_before flag, and simply evaluate whether all required fields are filled in (non-blank) before determining whether to send the user to the "Create New User" page or the "Edit Account Info" page.

NOTE: Obviously there are a lot of assumptions and serious design issues painted in this example, but it is included here because this *specific* case has happened often enough to motivate this point on parsimony. Numerous other issues beyond the scope of this note are excluded.

In Summary: Be Stingy with your Parameters and Variables

Unlike with humans, where it is good to paraphrase and say the same thing in multiple variations so as to get your point across, this practice of redundancy is not as generously rewarded in the programming realm. Keep the parameters to a minimum, say things as parsimoniously as possible, and you will minimize the number of ways things can go wrong in your code.

In reply to Basic Coding Tips: Parsimonious Parameterization by dimar

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others about the Monastery: (11)
    As of 2018-06-22 12:03 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (124 votes). Check out past polls.