writing thorough function specifications & documentation
writing robust unit tests for these functions to ensure they work as expected
writing the code that makes up the function body
If you are using R, these functions will live in an .R file (whose filename will be named after the function, or functions). It is OK to have one function per file, or all functions in one file. This/these file(s) will live in a sub-directory called R. If you are using Python, these functions will live in an .py file (whose filename will be named after the function, or functions). Again, it is OK to have one function per file, or all functions in one file. This/these file(s) will live in a sub-directory called src.
You will source (in the case of R) or import (in the case of Python) these functions in your scripts to use them in your analysis. Tests will live in a test directory, with files/subdirectories organized as per the testing framework you are using. If you are using R for your data analysis code, we expect you to use the testthat R package framework for writing software tests. If you are using Python, we expect you to use the pytest Python package framework.
Of course, if it makes sense to have more than 3-4 you are welcome to increase the number! However, all functions must have the same standards in regards to software robustness. Your functions will be assessed for their quality (e.g., functions should do one thing, and generally return an object unless they were specifically designed for side-effects), usability, readability (follow the tidyverse style guide for R, or the black style guide for Python), documentation and quality of the test suite.
writing thorough function specifications & documentation writing robust unit tests for these functions to ensure they work as expected writing the code that makes up the function body If you are using R, these functions will live in an .R file (whose filename will be named after the function, or functions). It is OK to have one function per file, or all functions in one file. This/these file(s) will live in a sub-directory called R. If you are using Python, these functions will live in an .py file (whose filename will be named after the function, or functions). Again, it is OK to have one function per file, or all functions in one file. This/these file(s) will live in a sub-directory called src.
You will source (in the case of R) or import (in the case of Python) these functions in your scripts to use them in your analysis. Tests will live in a test directory, with files/subdirectories organized as per the testing framework you are using. If you are using R for your data analysis code, we expect you to use the testthat R package framework for writing software tests. If you are using Python, we expect you to use the pytest Python package framework.
Of course, if it makes sense to have more than 3-4 you are welcome to increase the number! However, all functions must have the same standards in regards to software robustness. Your functions will be assessed for their quality (e.g., functions should do one thing, and generally return an object unless they were specifically designed for side-effects), usability, readability (follow the tidyverse style guide for R, or the black style guide for Python), documentation and quality of the test suite.