From ab908c61046682fdce0627237306307b82865b74 Mon Sep 17 00:00:00 2001 From: Brett Klamer Date: Fri, 26 Aug 2016 08:40:35 -0400 Subject: [PATCH] Fixing typos in functions.Rmd (#307) --- functions.Rmd | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/functions.Rmd b/functions.Rmd index e27ef00..7bfbfa8 100644 --- a/functions.Rmd +++ b/functions.Rmd @@ -180,7 +180,7 @@ This is an important part of the "do not repeat yourself" (or DRY) principle. Th It's important to remember that functions are not just for the computer, but are also for humans. R doesn't care what your function is called, or what comments it contains, but these are important for human readers. This section discusses some things that you should bear in mind when writing functions that humans can understand. -The name of a function is important. Ideally, the name of your function will be short, but clearly evoke what the function does. That's hard! But it's better to be clear than short, as RStudio's autocomplete makes it easy to type long names. +The name of a function is important. Ideally, the name of your function will be short, but clearly evoke what the function does. That's hard! But it's better to be clear than short, as RStudio's autocomplete makes it easy to type long names. Generally, function names should be verbs, and arguments should be nouns. There are some exceptions: nouns are ok if the function computes a very well known noun (i.e. `mean()` is better than `compute_mean()`), or accessing some property of an object (i.e. `coef()` is better than `get_coefficients()`). A good sign that a noun might be a better choice is if you're using a very broad verb like "get", "compute", "calculate", or "determine". Use your best judgement and don't be afraid to rename a function if you figure out a better name later. @@ -625,7 +625,7 @@ rule <- function(..., pad = "-") { rule("Important output") ``` -Here `...` lets me forward on any arguments that I don't want to deal with to `str_c()`. It's a very convenient technique. But it does came at a price: any misspelled arguments will not raise an error. This makes it easy for typos to go unnoticed: +Here `...` lets me forward on any arguments that I don't want to deal with to `str_c()`. It's a very convenient technique. But it does come at a price: any misspelled arguments will not raise an error. This makes it easy for typos to go unnoticed: ```{r} x <- c(1, 2) @@ -718,7 +718,7 @@ This tends to make the code easier to understand, because you don't need quite s ### Writing pipeable functions -If you want to write your own pipeable functions, thinking about the return value is important. There are two main types of pipeable functions: transformation and side-effecty. +If you want to write your own pipeable functions, thinking about the return value is important. There are two main types of pipeable functions: transformation and side-effect. In __transformation__ functions, there's a clear "primary" object that is passed in as the first argument, and a modified version is returned by the function. For example, the key objects for dplyr and tidyr are data frames. If you can identify what the object type is for your domain, you'll find that your functions just work with the pipe.