# Optional function arguments / cell annotations

**URL:** <https://talk.observablehq.com/t/optional-function-arguments-cell-annotations/509>\
**Category:** Feedback\
**Created:** [March 16, 2018, 12:54pm UTC](https://talk.observablehq.com/t/optional-function-arguments-cell-annotations/509 "2018-03-16T12:54:56Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kelleyvanevert](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/kelleyvanevert/32/169_2.png) [@kelleyvanevert](https://talk.observablehq.com/u/kelleyvanevert)\
**Post date:** [March 16, 2018, 12:54pm UTC](https://talk.observablehq.com/t/optional-function-arguments-cell-annotations/509/1 "2018-03-16T12:54:56Z")

</div>

I often find myself following the workflow of slowly transforming the cells with code that I’m working on, to helper functions, accumulating these ‘helper function cells’ as I go. Because I love the aspects of Observable that make it ‘accessible’ (for teaching, explaining, understanding code, etc), I also like to annotate these functions with their types (or, a high level human readable version of these) by using `viewof` and an auxiliary helper (like `def(annotation, fn)`) instead of having them just display as “f somefunc(…)” (which is already pretty, btw). (See image below.)

**Optional function arguments**  
It is noteworthy that optional parameters to function disappear in the cell’s automatic display. (I.e. if a function takes optional parameters, the cell’s display changes from “f somefunc(a,b)” to “f somefunc(…)”). I think a small effort to show optional parameters would greatly improve the understandability of a notebook. (Being able to understand a cell at a glance, instead of having to open/close it.)

**Cell annotations**  
This one’s just a wild idea. Focusing on the aim to encourage people to write their notebooks in such a way that they can be ‘read’ in an informative way (i.e. notebooks as a method of sharing knowledge and examples, as distinct from: notebooks as an iterative, feedback-oriented method of developing code) — I think it might be useful to provide notebook writers direct / easy means to give notebook readers an idea of what’s inside a collapsed cell. (Pinning a cell open isn’t always the best thing to do, too much code at once can be daunting to a reader.) My method of using `viewof` and an auxiliary `def` helper is possible, but maybe it would be encouraging to notebook writers to work this way if something would be built in for this particular case. For example, an `annotate` operator, that could be used like thus:

```
somefunc = function (a,b) {
  ...
}

annotate md`This is a function that ...`

```

…so that the collapsed cell would display as:

> _f_ somefunc(a,b)
> 
> This is a function that…

This would be a ‘open’ solution, leaving the possibilites open to the creativity of the community (who know, maybe people will start annotating their functions with cool interactive displays of what the function does, or …).

 ![Screenshot%20from%202018-03-16%2013-15-59-s](https://canada1.discourse-cdn.com/flex030/uploads/observablehq/original/1X/02d1e653dab7c03bff556df77fcf545cb8588ac3.png)

---

<div class="post-metadata">

**Author:** ![tom](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/tom/32/2262_2.png) [@tom](https://talk.observablehq.com/u/tom)\
**Post date:** [March 18, 2018, 6:58am UTC](https://talk.observablehq.com/t/optional-function-arguments-cell-annotations/509/2 "2018-03-18T06:58:03Z")

</div>

Hi Kelley!

Cool, so:

- **Optional function arguments** : yep! We originally included them in our function formatting, because we were essentially stringifying functions and being very liberal about what we showed, but the current formatting is much more conservative - it parses argument names and bails out if we see a `=`. The rationale there is that optional function arguments can have _anything_ as a value - even a gigantic JavaScript expression - and we still need to figure out where to draw the line - which kinds of function arguments should be shown in the short version. Perhaps we can just say, literals get printed, everything else collapsed?
- Annotations - we’d love something like python’s docstrings or clojure’s meta system to be a reality in JavaScript, and [I’ve been tinkering with the idea](https://github.com/tmcw/dx-spec/issues/7). It’ll likely require a new spec and documentation ecosystem, but the payoffs - not only getting nice output in Observable but also getting inline documentation from 3rd party libraries - makes it something that we’re all pretty game to invest some time in.

-Tom