# Feedback requested: Parameter style in sample code

**URL:** <https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619>\
**Category:** Making Packs\
**Created:** [May 11, 2022, 3:44pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619 "2022-05-11T15:44:44Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\
**Post date:** [May 11, 2022, 3:44pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/1 "2022-05-11T15:44:44Z")

</div>

Hi Pack Makers!

One of my goals with the Pack SDK documentation is creating sample code that balances readability with being realistic. However when it comes to how parameters are passed to a formula’s `execute` function I’m not sure I’m living up to that ideal. Please take a look at the options below and let me know which you think would be the most helpful as you learned the platform.

## Option 1: Parameter destructuring

```ts
  execute: async function ([text, volume = 3, character = "!"], context) {
    // ...
  },

```

This is the pattern we currently use in the documentation. It’s succinct, but cramming so much in to one line could be hurting readability.

## Option #2: Descruturing in the function

```ts
  execute: async function (parameters, context) {
    let [text, volume = 3, character = "!"] = parameters;
    // ...
  },

```

This options moves the destructuring down to the first line of the function. This makes it clearer than the first parameter to the `execute` function is all of the parameters.

## Option #3: One at a time

```ts
  execute: async function (parameters, context) {
    let text = parameters[0];
    let volume = parameters[1] ?? 3;
    let character = parameters[2] ?? "!";
    // ...
  },

```

This option makes it more explicit where each parameter comes from, at the expense of it being more verbose.

## Option #4: Explicit defaults

```ts
  execute: async function (parameters, context) {
    let text = parameters[0];
    let volume = parameters[1];
    if (volume == undefined) {
      volume = 3;
    }
    let character = parameters[2];
    if (character == undefined) {
      character = "!";
    }
    // ...
  },

```

This option removes all modern JavaScript “magic”, setting the default value for parameters in the most explicit way. This option is the most verbose however, adding 9 lines compared to the original.

---

<div class="post-metadata">

**Author:** ![Thomas\_Baucom](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/thomas_baucom/32/26289_2.png) [@Thomas\_Baucom](https://connect.superhuman.com/u/Thomas_Baucom)\
**Post date:** [May 11, 2022, 3:59pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/2 "2022-05-11T15:59:07Z")

</div>

Honestly, I think after seeing the four options, Option #1 still is the one I personally prefer. I will grant you that it could most likely be because it is also what I have referenced while I learned.

If I were looking for a goldilocks option, Option #2 is probably the “cleanest” example if I was just coming into it for the first time.

---

<div class="post-metadata">

**Author:** ![Leandro\_Zubrezki](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/leandro_zubrezki/32/35032_2.png) [@Leandro\_Zubrezki](https://connect.superhuman.com/u/Leandro_Zubrezki)\
**Post date:** [May 11, 2022, 4:14pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/3 "2022-05-11T16:14:28Z")

</div>

> [@Eric\_Koleda](#):
>
> ## Option #2: Descruturing in the function
> 
> ```auto
> execute: async function (parameters, context) {
> let [text, volume = 3, character = "!"] = parameters;
> // ...
> },
> 
> ```
> 
> This options moves the destructuring down to the first line of the function. This makes it clearer than the first parameter to the `execute` function is all of the parameters.

Option 2 is the best one for me, I would just use `const` instead of `let`. The reason why 1 is problematic is when you have many parameters but I use it when just a couple or also an empty array when no parameters.

---

<div class="post-metadata">

**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\
**Post date:** [May 11, 2022, 4:27pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/4 "2022-05-11T16:27:55Z")

</div>

> [@Leandro\_Zubrezki](#):
>
> I would just use `const` instead of `let`

That’s a whole separate debate! I drafted a style guide when I started creating the sample code that selected `let` over `const` in most situations:

 ![Screen Shot 2022-05-11 at 12.23.04 PM](https://global.discourse-cdn.com/coda1/original/3X/a/4/a46bd52c57d113565d3d4b41fc579247d4a63f64.png)

My take is that `const` is good at securing your code against accidental changes once you know what you want it to do, but when you are in the messy experimentation phase it can be a bit limiting and frustrating.

---

<div class="post-metadata">

**Author:** ![Max\_OBrien](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/max_obrien/32/49285_2.png) [@Max\_OBrien](https://connect.superhuman.com/u/Max_OBrien)\
**Post date:** [May 11, 2022, 11:07pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/5 "2022-05-11T23:07:51Z")

</div>

@Eric_Koleda ,

option #2 is by far the best i.m.h.o.  
and use ‘let’ rather than ‘const’.

i have been teaching js & python to kids in the [https://coderdojo.com](https://coderdojo.com) for some years now.

those who are new to js can get badly confused when we mix json objects into our arguments. the tiny signs like the square brackets, so clear to us, are all but invisible to newbies. so to them option#1 seems to have many arguments when it actually has only 2.

that is much clearer in option #2 while still being far more succinct than the other following options.

and ‘let’ is a simple meaningful verb whereas ‘const’ is not.

the template code used on the browser pack editor mixes declarative js code with json object definitions quite freely.

in my experience, this confuses less experienced coders.

some curly braces demark declarative blocks while some are objects within a json definition. but which is which?

a confusion of brackets, commas, colons and semicolons can overwhelm someone not used to this style of coding.

you need quite an accurate lexical analyzer running in your head when you read such code.

so any steps you take to seperate the json from the pure js syntax is a great aid to understanding on my opinion.

respect  
max

---

<div class="post-metadata">

**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\
**Post date:** [May 12, 2022, 12:18am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/6 "2022-05-12T00:18:02Z")

</div>

Thanks for the detailed feedback @Max_OBrien! I have also seen the mixture of syntaxes tripping up some newer coders. Any ideas on how we could avoid some of that in the Packs sample code?

---

<div class="post-metadata">

**Author:** ![Breno\_Nunes](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/breno_nunes/32/12706_2.png) [@Breno\_Nunes](https://connect.superhuman.com/u/Breno_Nunes)\
**Post date:** [May 12, 2022, 3:14am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/7 "2022-05-12T03:14:33Z")

</div>

As a newbie who wrote a pack as my first JavaScript code, I would definitely go for the first option.  
It’s one less line of code to understand compared to the 2nd option.  
I don’t mind all the signs as it’s a must learn thing in JavaScript.

---

<div class="post-metadata">

**Author:** ![Max\_OBrien](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/max_obrien/32/49285_2.png) [@Max\_OBrien](https://connect.superhuman.com/u/Max_OBrien)\
**Post date:** [May 12, 2022, 10:33am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/8 "2022-05-12T10:33:53Z")

</div>

@Eric_Koleda

i dont think a major change of style is needed, its good solid ‘best practice’ code and newbies need to learn to work with that style

but

it WOULD be helpful to place some comments and blank lines at the interfaces between pure js statements and the embedded json objects

a small comment saying //JSON begin  
and //JSON end  
above and below any json objects is all thats needed

in my humble opinion

respect  
max

---

<div class="post-metadata">

**Author:** ![Daniel\_Stieber](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/daniel_stieber/32/17045_2.png) [@Daniel\_Stieber](https://connect.superhuman.com/u/Daniel_Stieber)\
**Post date:** [May 12, 2022, 11:04am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/9 "2022-05-12T11:04:07Z")

</div>

I didn’t even know that you can do #2 🤔😃

It seems definitely the smoothest one, but with my dev level I have to agree with @Breno_Nunes that #1 is way more clear to understand. In #2 I would not understand how to access the variables and that some of them are default values. In #1 it is clear to me.

At least I learned something today 🙂

---

<div class="post-metadata">

**Author:** ![Scott\_Collier-Weir](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/scott_collier-weir/32/29677_2.png) [@Scott\_Collier-Weir](https://connect.superhuman.com/u/Scott_Collier-Weir)\
**Post date:** [May 13, 2022, 3:02am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/10 "2022-05-13T03:02:26Z")

</div>

I want to agree with @Breno_Nunes

As a new coder myself, the added lines of code in the latter options are more confusing.

I vote Option 1! It’s also more in line with what I’ve learned in any programming classes which is:

- parameters go in the parenthesis right after the function name.

In my mind that’s a hard and fast rule and all I’ve ever seen in learning to program type courses.

So option #1 all the way.

---

<div class="post-metadata">

**Author:** ![Pch](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/pch/32/17688_2.png) [@Pch](https://connect.superhuman.com/u/Pch)\
**Post date:** [May 13, 2022, 8:14am UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/11 "2022-05-13T08:14:45Z")

</div>

> [@Max\_OBrien](#):
>
> those who are new to js can get badly confused when we mix json objects into our arguments. the tiny signs like the square brackets, so clear to us, are all but invisible to newbies. so to them option#1 seems to have many arguments when it actually has only 2.

I just want to say 👆 This 👆 !

I’ve tried to create a pack some time ago and I felt lost faster than I thought I would 😅 (and because I don’t like that feeling, I’m currently trying to learn some JS when I’ve got the time 😇 … Strangely enough, I’m not that bad at reading it… but producing it, it’s a complete different story 😅 … I’m very slowly getting there though)

I don’t want to interfere here, as I’m at the other side of the galaxy from getting near packs but the Option 2 was still pretty understandable 😊

---

<div class="post-metadata">

**Author:** ![Lynn\_vK](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/lynn_vk/32/26525_2.png) [@Lynn\_vK](https://connect.superhuman.com/u/Lynn_vK)\
**Post date:** [May 13, 2022, 2:06pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/12 "2022-05-13T14:06:48Z")

</div>

Newbie here! I learn quite a bit from looking at the code with comments. Example #2 works best for me, and adding even more explanatory comments would be useful, as suggested by Max. I appreciate Eric’s efforts to make the code easy to decipher for non-coders because it will lower the barrier to entry. Also, it was not clear to me when starting with Packs that the Coda JS language was different from the JS that is taught in online courses. (My favorite course thus far has been [codewithmosh.com](http://codewithmosh.com). It’s only $15!) Going back and forth between the 2 JS versions has been a challenge.

---

<div class="post-metadata">

**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\
**Post date:** [May 13, 2022, 4:42pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/13 "2022-05-13T16:42:14Z")

</div>

Thanks everyone for the thoughtful feedback! I haven’t made any sweeping changes to the existing samples just yet, but I did just publish a new tutorial and went with option #2 based on your feedback:

> **[Learn to build a formula - Coda Pack SDK](https://coda.io/packs/build/latest/tutorials/build/formula/)**
>
> Documentation for the SDK to build Coda Packs.

(You made need to shift-refresh to get the latest updates to the CSS stylesheet.)

Give it a read and let me know if this “unpacking” metaphor makes sense. Any other feedback welcome as well, as I plan to create more tutorials using this format.

---

<div class="post-metadata">

**Author:** ![Lynn\_vK](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/lynn_vk/32/26525_2.png) [@Lynn\_vK](https://connect.superhuman.com/u/Lynn_vK)\
**Post date:** [May 13, 2022, 5:28pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/14 "2022-05-13T17:28:38Z")

</div>

Your formula tutorial is fantastic! What a great idea to start with the simple structure (scaffolding) and then adding some minimal complexity, step-by-step, with testing. Also, the links to the JavaScript.info tutorial are useful to supplement and add context to your instructions. Would you consider adding the simple code for a column format as an additional step, or would that add to much complexity? (It took me a while to figure out that the column format code and formula code could be included in the same build.) More tutorials like this one will be super useful! 👏

---

<div class="post-metadata">

**Author:** ![Scott\_Collier-Weir](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/scott_collier-weir/32/29677_2.png) [@Scott\_Collier-Weir](https://connect.superhuman.com/u/Scott_Collier-Weir)\
**Post date:** [May 13, 2022, 5:51pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/15 "2022-05-13T17:51:49Z")

</div>

This doesn’t change how we can actually type in, reference parameters in our packs does it?

---

<div class="post-metadata">

**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\
**Post date:** [May 13, 2022, 6:25pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/16 "2022-05-13T18:25:48Z")

</div>

Thanks for the feedback @Lynn_vK! I think that tutorial is already a bit long, but I’ll add a TODO to create a tutorial for column formats, perhaps building off of that code.

@Scott_Collier-Weir - Not at all! All four of the options in the original post work now and will continue to work. I’m just trying to figure out how best to demonstrate these concepts in the docs.

---

<div class="post-metadata">

**Author:** ![Nick\_HE](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/nick_he/32/6190_2.png) [@Nick\_HE](https://connect.superhuman.com/u/Nick_HE)\
**Post date:** [May 17, 2022, 11:07pm UTC](https://connect.superhuman.com/t/feedback-requested-parameter-style-in-sample-code/30619/17 "2022-05-17T23:07:26Z")

</div>

Missed this post initially. Good question!

I’m in the #2 camp too (maybe #1, but #1 is pretty heavy on the magic).

It’s hard to get around an underlying ambiguity which is that, while your destructured variable names will often match your parameter names, in truth that’s entirely coincidental; all that matters is their position in the parameters array. I can see that tripping folks up when they add/remove or reorder parameters. But I think making it explicit with the array references in #3/#4, results in an intimidating wall of code that’s not worth it.