Author: Meike Snijder-Steinhilber
Date: 2026-05-06

# Developer Guide: sprtt Package

#### Meike Snijder-Steinhilber

#### 2026-05-06

## Overview

This vignette provides technical documentation for developers who want to maintain, extend, or contribute to the `sprtt` package. It explains the internal architecture, code organization, computational methods, and development workflows.

Target audience: R package developers, future maintainers, and contributors

Prerequisite knowledge:

- R package development basics
- S4 object-oriented programming
- Statistical knowledge of Sequential Probability Ratio Tests, see `vignette("sprt")`

## Package Architecture

### Overview

The `sprtt` package follows a modular architecture with clear separation of concerns:

1. Main User-facing functions (`seq_ttest()`, `seq_anova()`) handle input validation and provide clean interfaces

2. Utility User-facing functions provide supporting functionality (plotting, data generation, caching)

3. Builder functions (`build_seq_*_arguments()`) Transform and validate user inputs into a structured S4 argument object. Builder functions act as a processing pipeline between the user-facing interface and the core calculation functions. They handle the complex task of parsing different input formats, validating all parameters, and packaging everything into a type-safe container.

4. Calculation functions (`calc_seq_*()`) perform the core computations

5. Internal utility functions (e.g., `delete_na()`, `extract_formula()`, `get_seq_decision()`, …) are small, focused helpers that handle specific tasks across the package. They follow the Single Responsibility Principle - each function does one thing well. This design reduces code duplication, improves testability, and makes the codebase easier to maintain.

6. Result Classes - S4 classes that store results in type-safe, structured containers. These classes provide controlled access to result components through standardized methods (`@`, `[]`, and `show()`), ensuring consistency and extensibility.

This separation allows for:

- Easy testing of individual components
- Clear error handling at appropriate levels
- Extensibility for future sequential tests
- Consistent user experience across functions

Function Naming Convention:

- `seq_*()`: User-facing main functions
- `build_*()`: Argument preparation functions
- `calc_*()`: Computational core functions
- `*_class.R`: S4 class definitions

### Function Structure

Table: Structure of the main `seq_ttest()` function (Level 1)

Level 2 | Level 3 | Level 4
--- | --- | ---
`build_seq_ttest_arguments()` Class: seq_ttest_arguments | `check_formula()` |
| `extract_formula()` |
| `get_one_sample()` |
| `delete_na()` |
| `check_data()` | `check_constant_data()`
`calc_seq_ttest()` Class: seq_ttest_results | `calc_seq_ttest_t_statistic()` |
| `calc_seq_ttest_non_centrality_parameter()` |
| `calc_seq_ttest_likelihoods()` |
| `calc_seq_ttest_boundaries()` |
| `get_seq_ttest_decision()` |
| `build_seq_ttest_results()` |

Table: Structure of the main `seq_anova()` function (Level 1)

Level 2 | Level 3
--- | ---
`build_seq_anova_arguments()` Class: seq_anova_arguments | `check_formula_anova()`
| `extract_formula_anova()`
| `check_data_anova()`
`calc_seq_anova()` Class: seq_anova_results | `calc_non_centrality_parameter_anova()`
| `calc_group_means()`
| `calc_ss_effect()`
| `calc_ss_residual()`
| `calc_ss_total()`
| `calc_F_statistic_()`
| `calc_likelihoods_anova()`
| `calc_boundaries()`
| `get_seq_decision()`
| `calc_effect_sizes()`
| `build_seq_anova_results()`
`calc_plot_anova()` Class: seq_anova_results |

## Software Testing

### Continuous Integration

## GitHub Structure

## Release Checklist

### Pre-release

- Update version number in DESCRIPTION
- Update NEWS.md with all changes
- Run `devtools::check()` - must pass cleanly
- Update documentation: `devtools::document()`
- Rebuild vignettes: `devtools::build_vignettes()`
- Test on multiple platforms (rhub, win-builder)
- Update README if needed
- Check all examples run correctly
- Verify all URLs in documentation are valid
- Run code coverage: `covr::package_coverage()`
- Update copyright year if needed

### CRAN Submission

- Prepare cran-comments.md
- Submit to CRAN: `devtools::release()`
- Monitor email for CRAN response
- Check CRAN package page after acceptance

### Post-release

- Create GitHub release with tag
- Tweet/announce new version
- Update pkgdown site: `pkgdown::build_site()`
- Increment development version number
- Update NEWS.md with “Development version” section

## Contributing

How to contribute:

1. Fork the repository
2. Create a feature branch
3. Make changes with tests
4. Submit pull request
5. Respond to review comments

Contribution guidelines:

- Follow existing code style
- Add tests for new features
- Update documentation
- Keep commits focused and atomic
- Write clear commit messages