L03 — Working in Notebooks / RStudio; Scripts & Projects

1Objectives¶

By the end of this lesson you will be able to:

1. Identify the main parts of the RStudio window and a Jupyter notebook.

2. Explain why code runs top-to-bottom, in order, and why that order matters.

3. Create and use an RStudio Project (or a JupyterHub lab folder) so your file paths work no matter whose computer runs the code.

4. Save and organize your R work in a way that survives past a single session.

2The RStudio window, in four panes¶

When you open RStudio, you see four panes (their exact position can be customized, but the defaults are):

The key habit: write your real code in the Source pane and save it as a script, rather than typing directly into the Console. The Console is great for a quick check, but anything typed only there disappears when you close RStudio — it was never saved anywhere.

3Jupyter notebooks: cells instead of a script + console¶

A Jupyter notebook (.ipynb, used on the CSUB JupyterHub) organizes work differently: the whole notebook is a sequence of cells. Each cell is either:

• a code cell — R code that runs and shows its output directly underneath, right in the notebook, or

• a Markdown cell — formatted text (headings, explanations) with no code.

You run a code cell with Shift+Enter (run this cell, move to the next) or Ctrl+Enter (run this cell, stay put). The lab notebooks for this course are built this way: text explaining a step, then a code cell that does it, in alternating order.

4Why execution order matters¶

Both RStudio scripts and Jupyter notebooks run top to bottom, one line (or cell) at a time, and R only knows about something after the line that creates it has actually run. This trips up nearly everyone at least once, so let’s see it happen.

Suppose your script creates an object:

x <- 5
y <- x * 2
y

[1] 10

That works because line 1 runs before line 2, which runs before line 3. But if you jump ahead and ask for something before it exists — say, you reference an object z you meant to create but haven’t yet, or you ran cells out of order — R gives you a clear error:

z

Error: object 'z' not found
Execution halted

This is not a bug in R; it is R correctly telling you it has no idea what z is yet. The fix is almost always the same: re-run your script (or notebook) from the top, in order, so every object exists before you use it. RStudio’s “Source” button and Jupyter’s “Restart & Run All” menu option both do exactly this in one click — a good habit before you consider any work finished, since it proves your code actually runs start to finish for someone else (including graded work being reproduced by your instructor).

5Projects: making file paths work on any computer¶

R needs to know where to look when you tell it to read a file, like read.csv("data/survey_sim.csv") (L06). That “where” is called the working directory. getwd() prints it:

getwd()

[1] "C:/Users/ayatawara/Documents/1. Research next generation/CSU LIFT/coordinator/math2200/r-help"

(Your own output will show a different path — this is the folder on the computer that produced this book. That’s expected and fine.)

If your code says read.csv("data/survey_sim.csv") — a relative path, meaning “starting from wherever I currently am” — it only works when your working directory is the right folder. This is the single most common source of “file not found” errors for beginners (L14), and the fix is the same for both interfaces:

• In RStudio: create an RStudio Project (File → New Project → Existing Directory, pointed at your course folder). Opening that .Rproj file automatically sets your working directory to that folder, every time — no setwd() needed, and no path breaks when you move the folder or hand it to someone else, as long as the relative structure inside it (like a data/ subfolder) stays the same.

• On the JupyterHub: your working directory is wherever the notebook file itself lives. As long as a data/ folder sits next to the notebook (which is how the labs are packaged), relative paths like "data/survey_sim.csv" work without any setup.

list.files() shows you what’s actually in a folder from wherever you currently are — a quick way to sanity-check before you try to read something:

list.files("data")

[1] "make_survey_sim.R" "survey_sim.csv"

And once the working directory is right, a relative path just works:

survey_peek <- read.csv("data/survey_sim.csv")
nrow(survey_peek)

[1] 120

6Saving and naming your work¶

• Scripts: save as .R files with short, descriptive names — hw3_analysis.R, not Untitled1.R.

• Notebooks: the JupyterHub saves .ipynb files automatically as you work, but download a copy for anything you want to keep past the term.

• Comment as you go. A line starting with # is a comment — R ignores it, but it tells the next reader (a grader, a classmate, or you in three weeks) what a step is for:

# Read the survey data and check how many students answered
survey_peek <- read.csv("data/survey_sim.csv")
nrow(survey_peek)

7Summary¶

• RStudio splits work across four panes; write real code in the Source pane and save it, don’t rely on the Console alone.

• Jupyter notebooks mix text and code cells, run with Shift+Enter, in order.

• Code runs top to bottom — referencing something before it’s created (or running cells out of order) causes an object not found error. “Run all from the top” is the standard fix and the standard sanity check.

• Use an RStudio Project locally (or rely on the JupyterHub’s notebook folder) so relative file paths like "data/survey_sim.csv" work on any computer, not just yours.