R_intro_9

problem –> { paper/brain/console } –> script –> …

• Write your code into scripts!
• Scripts are plain text files ending with .R
• It is usually better to have a script even for small tasks.

• comment why, (what), what is not working, TODO

• comment to organise code into logicle blocks (chunks)

• RStudio: comment line ending with at least four dashes (-), equal signs (=), or hashes (#) creates a code section.

• Rstudio: Ctrl + Shift + c

# ---- random numbers ---------------
x <- rnorm(10)
y <- rnorm(10) # inline comment

• Try to avoid long one-liners.
  
• Try to avoid “obscure” functions, tricks and workarounds.
  
• Use base R were you can*.
  
• Do not reinvent wheel but do not search for the solution longer then you would write it yourself.
  
• Write with (consistent) style.

* However consider e.g. tidyverse for its consistency

• input –> script –> output
  
  
  
• input is data (tables, binary, url)
  
• output is tables, images, whole analysis reports
  
  
  
• You want to be able to “run” the analysis the same way at any time with any data on input

• make small structured, commented script which takes input and generates output
  
• “source” the script
  

• individual images (png(), svg()) and text/tables (write.table())
  vs
  
• full report (html, pdf)
  
  
  
• R + LaTeX –> pdf (Sweave/knitr)
  
• R + markdown –> html (knitr)
  
• Markdown was designed for HTML, and LaTeX was for PDF
• pandoc to convert them all
  

• Rmarkdown = R + markdown
  
• require: rmarkdown (–> knitr + pandoc)
  
• *.Rmd –> *.md –> *.html
• backtick (grave accent): `
• code in chunks or inline
  

```{r chunk_name, option1=TRUE}
~60 chunk options, e.g.:

• gloal chunks options by opts_chunk$set(echo=FALSE, message=FALSE, warning=FALSE)

• YAML Ain't Markup Language
• yaml front matter for document global options
  

-–
title: “Best R analysis ever”
date: “24.12.2200”
author: “Me & Co.”
output: html_document
-–

markdown 3, markdown 4

• turn your script into Rmarkdown
  

• shiny turns analysis into interactive web application.

• interactive plotting (e.g. googleVis)

• presentations (e.g.slidify)

motivation for interactive reporting

• type and structure (e.g. data analysis project vs soft. devel. project)
• “implementation” (custom folder structure, RStudio project, R package (CRAN or BioC?))
• documentation
• version control
• sharing

• data_analysis_project
  • data/
  • code/
    • load.R
    • functions.R
    • do.R
  • bench/
  • results/
  • description.txt
    

• software_development_project
  • R/
  • DESCRIPTION
    

note: soft. devel. might be part of data analysis. How to combine them?

• package vs library
• R/ + DESCRIPTION = essentials
• + man/, README, …
  
• R packages … Hadley Wickham again

• Example: sigannotateboxplots

• options
• build tools –> package
• version control system (e.g. –> GIT (e.g. –> GitHub))

• start a project

• GIT (vsn, mercurial?)
• bitbucket has private repositories
• github has gists (Pastebin with git) (e.g. kinase consensus)

• start Rstudio project with GIT
• commit a change

• function is a name + arguments + body code
  
• convert code chunks into functions … When?
  
• Why a function:
  
  • easier to repeat code execution
    
  • less likely to make mistakes by changing the order and state of code chunk
    
  • sanity checks
    
  • no need to change variable names (if they are prameters)
    
  • DRY
• comments (may turn into documentation)
• code to function example

• TODO: knitcitations

script naming:

• files: R_intro_9.R
  
• variables (nouns): leuko_pat_1
  

• functions (verbs): countLeuko

• • pdf (pdf() or e.g. from knitted html via pandoc: pandoc -s R_intro_9.html -o R_intro_9.pdf)