When I was learning to program, one of the areas that tripped me up was the passing of data to otherwise unrelated areas of code via function calls with parameters. As I understand now, its hard to say what it was that was so prohibitive for me. I sorta got that this entity that is called a function is named as such because its supposed to serve as a gateway to using a chunk of code that serves a particular function and that you could pass in parameters that would alter the outcome of the code execution inside of the function. I think perhaps it was the flexibility of what could be passed and used that tripped me up, particularly as I have used scripting languages like JavaScript, PHP and Ruby the most.

On my morning commute, reading Nicholas Zakas' Maintainable JavaScript*, a way of thinking about functions popped into my head, along with the commentary that "I wish someone had described it to me this way when I was starting out". So here it is:

It makes sense to me to think about the second part of the function definition as a basket. A function definition is the first line of a function, typically where it is defined. It looks more or less like this, depending on the language (this is JavaScript):

makeCake = function(basket)

Furthermore, with language-dependent scoping issues aside, in this scenario makeCake() is something that receives deliveries. As you might guess, makeCake() is intended to take ingredients, bake a cake, and return it to you, at your 'return address'. This happens by assigning a variable that makeCake() will send the finished cake back to. Think of it as an inbox specially set up for you to receive the cake.

So, presumably through easy-to-read code, documentation and/or good communication, we know that makeCake() agrees to bake a cake for anyone who supplies the ingredients. It lets us know what it needs from us via its function definition:

makeCake = function(flour, sugar, eggs, oil)

So, let's see how we might use this with some JavaScript-flavored pseudo-code:


groceryStore = function (shoppingList) {
 // ... logic to assemble groceries
 return groceries;
}


makeCake = function(flour, sugar, eggs, oil) {
  // ... logic to bake a cake
  return cake;
}


throwParty = function() {
 var cakeIngredients = ['flour', 'sugar', 'eggs', 'oil'];
  /**
  * call groceryStore() and hand it our array of ingredients, which will return the items that we need
  * the groceries will be held in the 'ingredients' variable
  */
  var ingredients = groceryStore(cakeIngredients);


  /**
  * now, let's ask makeCake() to make the
  * cake for us with our ingredients
  * it will send back a cake and assign it to the 'cake' variable
  */
  var cake = makeCake(ingredients);
}


Appropriately, the program structure implied here is rather functional. Given that, you can think of the program execution as a bit like an assembly line via the mail, where each recipient makes a particular change to the object being shipped and passes it on. throwParty() decides what ingredients are needed and then asks groceryStore() to deliver it the ingredients. It can then in turn give those ingredients to makeCake() which, of course, makes a cake to give back to throwParty()

* The Amazon.com link is a referral link, so presumably if you bought the book via this link, I'd get a few cents or something. I added this on a whim and my rationale can be summed up with this phrase: "why not?"
I am pointing this out in the interest of full transparency and disclosure. If you want to buy the book and feel so inclined to use this link as you found out about it here, that would be nice of you.