# Chapter20Function Flashcards

1
Q

how to get help with if forinstance in R

A

?’if’

2
Q

You should not use | and & in IF statement

A
1. You can use||(or) and&&(and) to combine multiple logical expressions.
4. You should never use|or&in anifstatement: these are vectorised operations that apply to multiple values (that’s why you use them infilter()). If you do have a logical vector, you can useany()orall()to collapse it to a single value.
3
Q

usage of = , isidentical () in R. u need to be careful , why?

A
1. Be careful when testing for equality.==is vectorised, which means that it’s easy to get more than one output. Either check the length is already 1, collapse withall()orany(), or use the non-vectorisedidentical().identical()is very strict: it always returns either a singleTRUEor a singleFALSE, and doesn’t coerce types. This means that you need to be careful when comparing integers and doubles:
4
Q

if else , if else , what is the implication of have long chain of if else and what is the solution?

A

But if you end up with a very long series of chainedifstatements, you should consider rewriting. One useful technique is theswitch()function. It allows you to evaluate selected code based on position or name.

5
Q

Coding style of of using {} with if and function

A

Bothifandfunctionshould (almost) always be followed by squiggly brackets ({}), and the contents should be indented by two spaces.

n opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed byelse. Always indent the code inside curly braces.

example

if (y < 20) {
x

6
Q

Function argument data ? how many types?

A

The arguments to a function typically fall into two broad sets: one set supplies thedatato compute on, and the other supplies arguments that control thedetailsof the computation

Generally, data arguments should come first. Detail arguments should go on the end, and usually should have default values. You specify a default value in the same way you call a function with a named argument

The default value should almost always be the most common value. The few exceptions to this rule are to do with safety. For example, it makes sense forna.rmto default toFALSEbecause missing values are important. Even thoughna.rm = TRUEis what you usually put in your code, it’s a bad idea to silently ignore missing values by default.

``` When you call a function, you typically omit the names of the data arguments, because they are used so commonly. If you override the default value of a detail argument, you should use the full name:
# Good
mean(1:10, na.rm = TRUE)
# Bad
mean(x = 1:10, , FALSE)
mean(, TRUE, x = c(1:10, NA))```
7
Q

How to put space in function call ?

A

Notice that when you call a function, you should place a space around=in function calls, and always put a space after a comma, not before (just like in regular English). Using whitespace makes it easier to skim the function for the important components.

8
Q

Choosing names

A

Generally you should prefer longer, more descriptive names, but there are a handful of very common, very short names. It’s worth memorising these
§ x,y,z: vectors.
§ w: a vector of weights.
§ df: a data frame.
§ i,j: numeric indices (typically rows and columns).
§ n: length, or number of rows.
§ p: number of columns.

9
Q

How to check values and stop if not correct?

A

It’s good practice to check important preconditions, and throw an error (withstop()), if they are not true:

wt_mean

10
Q
1. Dot-dot-dot (…)
A

I do not understand

11
Q
1. Lazy Evaluation
A

Arguments in R are lazily evaluated: they’re not computed until they’re needed. That means if they’re never used, they’re never called. This is an important property of R as a programming language, but is generally not important when you’re writing your own functions for data analysis. You can read more about lazy evaluation

12
Q

Enviroment in R

A

The environment of a function controls how R finds the value associated with a name.

For example, take this function:
f [1] 110

This behaviour seems like a recipe for bugs, and indeed you should avoid creating functions like this deliberately

13
Q

Writing a function has three big advantages over using copy-and-paste:???

A

You can give a function an evocative name that makes your code easier to understand.

As requirements change, you only need to update code in one place, instead of many.

You eliminate the chance of making incidental mistakes when you copy and paste (i.e.updating a variable name in one place, but not in another).

Another advantage of functions is that if our requirements change, we only need to make the change in one place

Good code style is like correct punctuation.

14
Q

When should you write a function?

A

You should consider writing a function whenever you’ve copied and pasted a block of code more than twice (i.e.you now have three copies of the same code).

15
Q

Whare are the three key steps to creating a new function:

A

Pick a name

You list the inputs, orarguments, to the function insidefunction

You place the code you have developed inbodyof the function, a{block that immediately followsfunction(…).

It’s easier to start with working code and turn it into a function; it’s harder to create a function and then try to make it work.

It is good to check ur function wth diff input

16
Q

What is Unit Testing

A

As you write more and more functions you’ll eventually want to convert these informal, interactive tests into formal, automated tests. That process is called unit testing

17
Q

DRY …. function

A

This is an important part of the “do not repeat yourself” (or DRY) principle. The more repetition you have in your code, the more places you need to remember to update when things change (and they always do!), and the more likely you are to create bugs over time.

18
Q

Functions are for humans and computers , so advise on writing function? what are some advise?

A

Short Names: 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 thancompute_mean()), or accessing some property of an object (i.e.coef()is better thanget_coefficients()).

If your function name is composed of multiple words, I recommend using “snake_case”, where each lowercase word is separated by an underscore. camelCase is a popular alternative. It doesn’t really matter which one you pick, the important thing is to be consistent: pick one or the other and stick with it. R itself is not very consistent,
If you have a family of functions that do similar things, make sure they have consistent names and arguments. Use a common prefix to indicate that they are connected. This helps with R autocomplete feauture. Good
input_select()
input_checkbox()
input_text()

Not so good
select_input()
checkbox_input()
text_input()

A good example of this design is the stringr package: if you don’t remember exactly which function you need, you can typestr_and jog your memory

19
Q

Why do we overwrite existing function and variable?

A

avoid overriding existing functions and variables

20
Q

Why coment , and wht should we write in comment?

A

Use comment to write why not how and what

Use comments, lines starting with#, to explain the “why” of your code. You generally should avoid comments that explain the “what” or the “how”. If you can’t understand what the code does from reading it, you should think about how to rewrite it to be more clear.

Another important use of comments is to break up your file into easily readable chunks. Use long lines of-and=to make it easy to spot the breaks.

Load data ————————————–