Functions - aTbRef update

I’ve just updated aTbRef with recently emerging information on the workings of action code functions. That article and all its child notes should be read as a whole. As there isn’t a neat linear way to write the whole as a single article (plus it make fine referencing harder) it is split into a series of small notes.

As I’ve had some push-back on my aTbRef method of naming things, I would simply repeat the assertion that the stylised naming is there to help the learner, not the export. Those who already know where it is practical to use their own naming are free to do so.

Functions are a new and still evolving area and things may change. For instance, it is now clear that arguments (inputs) passed to a function arrive as strings—regardless of the type passed into the function. String, List and Dictionary types are fine but other may need passing into a suitably date-typed attribute or variable before further using the function. Of course if typed arguments become supported, all this guidance will be updated. But, it’s as correct as I can make it now.

This section on functions is a significant new addition to the aTbRef and I’d welcome feedback as to whether it does the job. Before replying a couple of provisos:

  • This is written for the learner, not the expert programmer: the latter already know where it is safe to act differently - the naming of things being the most obvious.
  • Please read the section (container note and 12 short child notes) as a whole before rushing to comment as the issue may be referred to in a note not yet read.

An aspect of understanding that was apparent as not being clear—from last weekend’s meet-up) is the naming of function arguments and loop variables. In both cases the user gets to name something that is then treated as if an attribute. Understanding is obvious after the fact, but I’m still looking for a different metaphor (maybe more than one is needed) to address this issue. A brief example, in the function context for a learner:

“The function is defined as fSomeFunction(aList){... but I need to pass it $MyList. How do I turn MyList into aList? It’s not explained?”. The answer is obvious if you know. Very hard to guess otherwise.

I’m open to ideas on the latter—preferably ones that don’t that require the reader to have (assumed) programming knowledge! :slight_smile:

6 Likes

Mark,

Thanks very much for this: very helpful, as always.

I’ve started to work through the sections and will report any comments as requested in due course, but thought I’d mention this straightaway:

AFAICT, the ‘Next’ links [see note below] are actually links to the page itself – i.e.

Next: Function Arguments

Actually points to Function arguments.

I’ve not checked them all, but it’s true for the first few I’ve checked.

[Note] this is for the white background left justified Next: link, just below the main text, not the standard grey background navigation footer section, which works as expected.

Only minor, but I thought I’d mention it.

Thanks for the resource, as always!

1 Like

Fixed!

Thank you - just the sort of helpful feedback needed. Yes, this was a coding slip-up on my part and as a result I found a few more formatting/typo issues and fixed them. These extra links are to help encourage new readers to read the whole ‘section’ of 12 notes about different aspects of action code functions.

Reports of errors are welcome! If I know about them I can fix them. :slight_smile:

2 Likes

Thanks again, Mark. It’s much appreciated.

Outstanding, @mwra!! Love this and will pore through as well.