AWSM packages and code script awsm1c2.pptx

AWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptxAWSM packages and code script awsm1c2.pptx

1. Hello…!! What are packages and code scripts BY: AMAN MALHOTRA

2. What are packages and code scripts The only hard rule is that your package should store its function definitions in R scripts, i.e. files with extension .R , that live in the R/ directory14. However, a few more conventions can make the source code of your package easier to navigate and relieve you of re-answering “How should I name this?” each time you create a new file. The Tidyverse Style Guide offers some general advice about file names and also advice that specifically applies to files in a package. We expand on this here.

3. The file name should be meaningful and convey which functions are defined within. While you’re free to arrange functions into files as you wish, the two extremes are bad: don’t put all functions into one file and don’t put each function into its own separate file. This advice should inform your general policy, but there are exceptions to every rule. If a specific function is very large or has lots of documentation, it can make sense to give it its own file, named after the function. More often, a single .R file will contain multiple function definitions: such as a main function and its supporting helpers, a family of related functions, or some combination of the two.

4. Another file you often see in the wild is R/utils.R. This is a common place to define small utilities that are used inside multiple package functions. Since they serve as helpers to multiple functions, placing them in R/utils.R makes them easier to re-discover when you return to your package after a long break. If it’s very hard to predict which file a function lives in, that suggests it’s time to separate your functions into more files or reconsider how you are naming your functions and/or files. The organisation of functions within files is less important in RStudio, which offers two ways to jump to the definition of a function:

5. Press Ctrl + . (the period) then start typing the name. Keep typing to narrow the list and eventually pick a function (or file) to visit. This works for both functions and files in your project. With your cursor in a function name or with a function name selected, press F2. This works for functions defined in your package or in another package. After navigating to a function with one of these methods, return to where you started by clicking the back arrow at the top-left of the editor or by pressing Ctrl + F9 (Windows & Linux) or Cmd + F9 (macOS).

6. Fast feedback via load_all() As you add or modify functions defined in files below R/, you will naturally want to try them out. We want to reiterate our strong recommendation to use devtools::load_all() to make them available for interactive exploration instead of, for example, source()ing files below R/. The main coverage of load_all() is in the workflows chapter and load_all() also shows up as one of the natural development tasks in the whole game. Compared to the alternatives, load_all() helps you to iterate more quickly and provides an excellent approximation to the namespace regime of an installed package.

7. Code style Although the style guide explains the “what” and the “why”, another important decision is how to enforce a specific code style. For this we recommend the styler package; its default behaviour enforces the tidyverse style guide. There are many ways to apply styler to your code, depending on the context: styler::style_pkg() restyles an entire R package. styler::style_dir() restyles all files in a directory. styler::style_file() restyles a single file. styler::style_text() restyles a character vector. When styler is installed, the RStudio Addins menu will offer several additional ways to style code: the active selection the active file the active package

8. Code style The use of Git or another version control system is optional, but a recommended practice in the long-term. We explain its importance in 18 . For example, it’s nerve-wracking and somewhat dangerous to apply a function like styler::style_pkg() without some way to see exactly what changed and to accept/reject such changes in a granular way. The styler package can also be integrated with various platforms for hosting source code and doing continuous integration. For example, the tidyverse packages use a GitHub Action that restyles a package when triggered by a special comment (/style) on a pull request. This allows mintainers to focus on reviewing the substance of the pull request, without having to nitpick small issues of whitespace or indentation1516.

9. Up until now, you’ve probably been writing scripts , R code saved in a file that you execute interactively, perhaps using an IDE and/or source(), or noninteractively via Rscript. There are two main differences between code in scripts and packages: In a script, code is run … when you run it! The awkwardness of this statement reflects that it’s hard to even think about this issue with a script. However, we must, in order to appreciate that the code in a package is run when the package is built . This has big implications for how you write the code below R/: package code should only create objects, the vast majority of which will be functions. Understand When Code is Executed

10. Functions in your package will be used in situations that you didn’t imagine. This means your functions need to be thoughtful in the way that they interact with the outside world.

11. Consider the assignment x <- Sys.time(). If you put this in a script, x tells you when the script was [source()](<https://rdrr.io/r/base/source.html>)d. But if you put that same code in a package, x tells you when the package binary was built . The main takeaway is this: Any R code outside of a function is suspicious and should be carefully reviewed. We explore a few real-world examples below that show how easy it is to get burned by this “build time vs. load time” issue. Luckily, once you diagnose this problem, it is generally not difficult to fix.

12. So dataTableDependency was an object defined in top-level package code and it depends on some paths obtained via [system.file()](<https://rdrr.io/r/base/system.file.html>). This works fine when the package is built and tested on the same machine. However, if the package is built on one machine and then used on another (as is the case with CRAN binary packages), then this will fail – the dependency will point to the wrong directory on the host. The heart of the solution is to make sure that [system.file()](<https://rdrr.io/r/base/system.file.html>) is called from a function, at run time. Indeed, this fix was made here (in commit 138db47 ) and in a few other packages that had similar code and a related check was added in htmlDependency() itself. This particular problem would now be caught by R CMD check, due to changes that came with staged installation as of R 3.6.0.

13. Available colors The crayon package has a function, crayon::show_ansi_colors() , that displays an ANSI colour table on your screen, basically to show what sort of styling is possible. In an early version, the function looked something like this:

14. where ansi_colors_8 and ansi_colors_256 were character vectors exploring a certain set of colours, presumably styled via ANSI escapes. The problem was those objects were formed and cached when the binary package was built. Since that often happens on a headless server, this likely happens under conditions where terminal colours might not be enabled or even available. Users of the installed package could still call show_ansi_colors() and num_colors() would detect the number of colours supported by their system (256 on most modern computers). But then an un-coloured object would print to screen (the original GitHub issue is r-lib/crayon#37 ). The solution was to compute the display objects with a function at run time (in commit e2b368a :

15. Literally, the same code is used, it is simply pushed down into the body of a function taking no arguments (similar to the shinybootstrap2 example). Each reference to, e.g., the ansi_colors_8 object is replaced by a call to the ansi_colors_8() function. The main takeaway is that functions that assess or expose the capabilities of your package on a user’s system must fully execute on your user’s system. It’s fairly easy to accidentally rely on results that were cached at build time, quite possibly on a different machine.

16. THANK YOU Coming Up Next Understanding Basics of Ubuntu Terminal