Ready4R (2025-24-03): Naming Variables, More Unit Testing, and Better Tables
Welcome to the Weekly Ready for R mailing list! If you need Ready for R course info, it's here. Past newsletters are available here.
Naming Variables
Naming variables is something that you've either spent a lot of time thinking about, or you've never thought about it. Crystal Lewis discusses in her book why you want to be consistent when you name variables, especially if you are unifying across years.
Chapter 9 Style Guide | Data Management in Large-Scale Education Research
Figure 9.1: Style guide development in the research project life cycle. A style guide provides general rules for the formatting of information. As mentioned in Chapter 8, style guides can be...
Unit Testing Part 4: Am I Doing This Right?
We all to some degree have a sense of impostor syndrome, and I think this is especially the case with more advanced development topics such as Unit Testing. There is always that sense that you're not doing it right, that there is a more optimal way to do it.
I just want to encourage you in your journey: the fact that you're thinking that means you are doing it right. Every development group has to come to terms with what the tests are supposed to accomplish.
Implementing tests is a learning process, because oftentimes when you release software to the public, you don't 100% know how people are going to use it, or want to use it. Your testing process will probably evolve as you move on.
Your tests should reflect your compassion for your user; understanding how they might approach your software, given their background. Your sample data should reflect the data they are trying to process in your package. If your package is for SAS users, like the {sassy} packages, they should act like SAS macros that your users are used to.
Testing is difficult because it is partially design-oriented. And design is an iterative process, so don't worry if you don't consider your tests complete.
How Many Tests do I need?
I would say the more your software is for public consumption, the more tests you should have. Making sure that you anticipate the ways that people will use your functions will help you determine which tests are the most important.
Sometimes it takes watching someone else who uses your software to optimize a lot of things, including tests. You also want to make sure that your tests don't take a long time to run, which is more important if you release your package on something like CRAN.
Better Tables
It has been a busy quarter for us at the Data Science Lab. We have been giving four different courses and multiple workshops, which include some new ones. One of our newest ones is called Better Tables.
The first part covers design principles of Tables, including how to guide people through your table. We compare before/after applying the principles, so you can decide which principles work for you.
The second part covers how to implement these principles in the gt/Great Tables packages. It includes both Python and R code.
Thanks again to Michael Chow and Rich Iannone for their reading recommendations.
Thanks for Reading!
Stay strong, everyone. We need to make our voices heard and get pissed off at our politicians if we want to affect change. The higher ups would rather we forget that we have power. We can see that we are changing things for the better by voting with our dollars and make our voices heard.
Best, Ted