https://handbook.gradientmetrics.com/product-team/coding/package-development/ Recent content in Package Development on Handbook Hugo -- gohugo.io https://handbook.gradientmetrics.com/product-team/coding/package-development/messages/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/messages/ Errors and warnings Alerts Inline text formatting Collapsing inline vectors Line breaks Headings Lists Bigger text paragraphs or code chunks Progress Bars Requesting user input Other things to be aware of Examples Let’s make console messages in our packages pretty and unified! Base R tools for this are quite limited, but luckily there’s a package called cli with a wide range of possibilities. https://handbook.gradientmetrics.com/product-team/coding/package-development/r-packages/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/r-packages/ Adding new R packages to our repository This has been automated with the g6tr_package_setup() function. But please recheck all the points manually. Create a new package inside the packages directory. Package folder should contain: R, tests, vignettes, data (optional), inst (optional), pkgdown folders DESCRIPTION, NEWS.md, .Rbuildignore files .Rprofile file. This should be the same as for all other packages. pkgdown/_pkgdown.yml file where functions and vignettes will be listed Nice to have: README. https://handbook.gradientmetrics.com/product-team/coding/package-development/deprecating-functions/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/deprecating-functions/ Introduction Further reads Application Introduction We encounter circumstances when a function requires significant modifications that might disrupt the flow of the original function (e.g., changing argument names, adding new arguments, etc.) or it simply need a thorough re-branding. Still, we don’t want to lose the existing function. It is feasible to notify existing users of those functions about the updates made so that people do not have to wonder why a function breaks or no longer works. https://handbook.gradientmetrics.com/product-team/coding/package-development/naming-rules/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/naming-rules/ General Data Frames Constants Examples Other variables Examples Functions Examples This guide explains how we name our code variables at Gradient. This refers to every R script we will ever create. Read through this and adhere to our protocol to improve collaboration! If a script in a Pull Request does not adhere to these naming rules, link to this page and let the coder update the names. https://handbook.gradientmetrics.com/product-team/coding/package-development/file-saving-rules/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/file-saving-rules/ Project files in a Repository R Data R Objects Project files in a Repository Our projects all follow the same structure as explained in Coding at Gradient Never use any of the following Unicode characters in your file names: < (less than) > (greater than) : (colon) " (double quote) / (forward slash) \ (backslash) | (vertical bar or pipe) ? https://handbook.gradientmetrics.com/product-team/coding/package-development/multicomponent-functions/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/multicomponent-functions/ Decomposition Checking inputs Decomposition If your function executes multiple non-trivial steps and these steps look like they could be encapsulated into separate functions on their own - then they almost always should. This is a bit vague instruction but it’s hard to put it more precisely without formalizing too many things thus making it practically unusable. Basically we have to keep in mind the ultimate goal here - we want to have functions that are easy to maintain. https://handbook.gradientmetrics.com/product-team/coding/package-development/data-pronoun/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/data-pronoun/ Reasons to use .data pronoun tidyselect > 1.2.0 and selecting Reasons to use .data pronoun We are extensively using tidyverse framework in our functions. You can find calls to dplyr’s or tidyr’s common functions in the majority of our code. Many of the functions use data-massking (see rlang data masking). In short, it means that you use the unqouted names passed to the function’s parameters. https://handbook.gradientmetrics.com/product-team/coding/package-development/import-tags/ Mon, 01 Jan 0001 00:00:00 +0000 https://handbook.gradientmetrics.com/product-team/coding/package-development/import-tags/ Using roxygen tags to import packages and functions Where should we put the import tags Using roxygen tags to import packages and functions We all stand on the shoulders of giants AKA we do extensively use functions written by other developers to create our own code. Using functions from other packages in our own packages, can be made in 3 ways: You can directly refer to package and function using package::fun() syntax in the code.