forked from hadley/r-pkgs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
best-practices.Rmd
40 lines (20 loc) · 1.41 KB
/
best-practices.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Best practices
"Each of you is perfect the way you are ... and you can use a little improvement."
--- Shunryu Suzuki
## Priority list
### Personal packages
Use RStudio.
Use RStudio Projects. Learn the keyboard shortscuts, especially Cmd + Shift + L for reloading all your code. Master the code development workflow of edit, reload and interactively test.
Use version control.
Use formal tests
Learn C++
### Shared packages
use roxygen
use github
use R CMD check
Release to CRAN.
## Development cycles
* fixing a bug/implementing a feature: edit -> load_all() -> interactive exploration -> write tests
* push to github: as above + check()
* use a branch: basically I only do this when I'm working on a package with someone else and either want to get their feedback before merging, or we're working simultaneously and I don't want to tread on their toes.
* release new version to CRAN: This tends to be mostly driven by external factors. Often I'll have some big picture plans for high profile packages (e.g. for each dplyr release I've had a pretty good feel for what the headline features will be), but for most of my smaller packages it's more driven by mental exhaustion from other projects, so I want something simple to do. Or github issues accumulate for several years, and then finally it tips the balance and I fix them all. Batching is super important so that I can avoid expensive context-switching