Is it possible you're running up against Project Options vs Global Options in RStudio? I have puzzled myself in this way with respect to other settings.
I dont use rm() as first line, and am slightly annoyed when I see others use it. It feels clutter-ish.
For most analysis projects, my first line is library(tidyverse)
This is also one of the great reasons to get familiar with packaging your analysis in an internal R package. My favourite way to deploy an analysis is to write an R package which the server then installs and runs, this helps with a few different things but one of them is that it helps you make sure that everything needed to run an analysis is present in the code. It ends up being a lot easier than it seems to get started with this stuff, and it really smooths the analysis -> sharing -> deployment curve.
I've learned a ton reading through these responses - thank you to everyone for sharing!
In all honesty, my first line is almost always a commented header with the project/script objective and the due date.
You know in rstudio you can have multiple projects up at the same time, right? Each w/ it's own global.
I never noticed that was in the desktop version before, or I might not have switched to primarily using the server.
Yes, I sometimes do that. but mostly try to focus on one thing at a time. I hadn't noticed the little button to the right of the project list items, that's handy. Thanks
library(methods)
This way any script using S4 classes won't fail when run non-interactively (e.g. via Rscript, where methods
is omitted from auto-attachment by default).
Depending on the way r is installed or preferences to put it in Rprofile, Sys.setenv(LANGUAGE = "en")
can also be a good candidate (for error messages in english).
Similarly on my Linux machine, I do Sys.setlocale("LC_MESSAGES", "en_US.UTF-8")
So many lines of code that comes handy - thank you all for sharing!
As @jessemaegan I start with commented header with project name, date, purpose and other extra information both for me and anyone else who uses the script.
Sometimes when it's just a quick thing, I go with Sys.setlocale("LC_CTYPE", "en_US.UTF-8")
, though.
I never use rm()
before, I tidy up R environment after each session. Does someone here does that too?
Depending on the project and analysis, I use options(scipen = 999)
to effectively remove scientific notation as one of my early (if not the first!) line of my R script.
I use rm(list = ls(all = TRUE))
a lot when I'm answering questions on Stack Overflow. Instead of continually restarting RStudio, I'd rather run this line of code when moving onto another question.
For the life of me, I have no idea why this isn't the default setting in RStudio.
I have started to use spin
via the 'Compile Report' button in RStudio, therefore my first line(s) of code is usually a yaml header. This way the script gets evaluated in a clean session and I get a nice html to look at. No need to remove anything at the beginning of the script. If I want to pass that script to anyone, I make sure to document thoroughly as this way (commented) code == documentation.
That doesn’t reset loaded packages so I’d recommend against relying on it to make reproducible examples. I think it’s better to learn the restart R keyboard shortcut and use that instead - I probably restart R >20 times a day.
Good point. My top three lines are usually:
library(tidyverse)
detach("package:some_package", unload = TRUE)
rm(list = ls(all = TRUE))
I'll give the reset R hotkey a try.
Edit: Wow, this is more convenient. Will be using the hot key for now on. Thanks for the tip
This is exactly like I work, always in a rmd so that everything is cleared. And I note down mine observations instructions and so on.
Thank you so much for that! It's one of those little inconveniences that I've had had for a long time.
Every time I was clicking on "Open Project in New Session..." I was thinking why there is no option to open the project from the same menu. Turns out there is
I also generally don't recommend using detach()
because there are some side-effects of loading a package (e.g. method registration, DLL loading) that are not always undone with detach()