Session 1 was the home page.

In Session 2, we are going to show you how to save this file, how to open it. We'll suggest you play with variables to get the hang of things. Then we will learn how to put that code into a function and register that with the system so it can be called again. That part was very not intuitive too.

Then we'll shadow a video on functions that gives good exposure on functions and output handling where the presenters sounds amazing, but in fact she leaves quite a bit to be desired for proper use of the console versus script files and good programming syntax in general.

When you hit "Source" it will in fact do a syntax check on it.

• If errors it will show those in the console.
• If not, IT WILL SAVE THE FILE AND IT WILL THEN SHOW UP AS AVAILABLE IN THE GLOBAL ENVIRONMENT.

Understanding Global Environment vs local or a more limited scope will likely become more relevant with time. Generally speaking, anyting registered as a Global Variable should be able to be called from anywhere. Just make sure you don't have multiple items in the Global Environment with the same names. I haven't tested it yet to see if it blocks that or not. Javascript does NOT block that. It registers one before another but you won't realize two are registered. The only way you figure it out is if you are making changes to code and running and still seeing old results. That's one way to know you have duplicate functions or objects or variables registered globally.

If you try to click Run, as you did when this code was NOT in a function wrapper, nothing happens.

The console may just show a second carrot. (2) . While we are here, there is a very subtle check mark looking icon related to the console (3). Use that to clear the console. I do that fairly regularly. You don't have to clear it but it helps when running code so you can more easily see where the messages starts for a new process.

At this point, you can test your function with a call from the console.

type func_eightGraphs() and hit enter...

and Whala!

NOTE: when calling a function you MUST have the () after the function name. If you just want to see the code of a function, leave off the () and instead of running it, it will simply get the text that is in the function...

Here's a list of the things I found confusing or that she did NOT explain with enough clarity. Her spoken presentation was fast and fluid, a smart person might have walked away feeling dumb, which is never the goal. She left out a TON that would leave most in the dark...

1) function naming -- NEVER name a function with a period somewhere in it. That could be totally confusing to any experienced programmer on first read. It would look like an object with a function parameter and leave them quite confused when they couldn't find the object (she names a function circle.area . Alternative choice would be circle_area. Also, my suggestion generally speaking is to name functions starting with "func" or somethign comparable to get into the habbit for larger work.

2) storing of functions in memory automatically happens from console -- for me, it was NOT intuitive that if I type a function into the console and hit enter, it gets saved in the global environment automatically. She implies or alludes to that but doesn't make that clear at all. Furthermore, once in the Global Environment, I can't figure out how to get it out?! In the environment tab, switch to GRID view, select the item you want to delete and use the 'broom' icon... https://support.rstudio.com/hc/en-us/community/posts/204888358-Delete-a-function-or-data-object-from-the-workspace

3) Trying to use console to create functions is absolute nightmare -- when trying to create functions in the console, if you accidentally submit it submits and no way to edit. If you make an err, no way to edit, can only delete from memory and redo. To get to the second and third lines, you need to remove the closing bracket from the function, etc. It's a keystroke nightmare. Create the functions in a script file like you learned prior, submit with the source button.

3) Naming of Variables -- She uses x for an array of values (also referred to as a vector of values by this group). In her two parameter output function, she has variables named area and circuference. Then she does a return like >> return ( c(Area = Area, Circumference = Circumference) . Variables should NEVER be named the same as what they are without some type of denotation. It confuses everything, especially those newer to programming. areaX and circumferenceX would have been far better variable names. Thus this would have read return ( c (Area = areaX, Circumference = circumferenceX) . This type of naming confusion is very common when folks who have not done a lot of programming start teaching before they've built larger systems. Likewise, when folks good at learning start regurgitating without thinking, this can happen too.

At 3:56, she mentions that return is NOT required. That the last expression calculated gets returned. She properly indicates you should always use a return call for clarity.

Below is an example where an array of values (a vector as she calls it) is fed into a function. Generally speaking, what's happening behind the scenes is a for each loop. I personally prefer to write my for each loops but this is a shortcut available to you with this system.