---
title: "Developer Guide: sprtt Package"
author: "Meike Snijder-Steinhilber"
date: "`r Sys.Date()`"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Developer Guide: sprtt Package}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---
```{r setup, include = FALSE}
knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>",
  eval = FALSE
)
```

## 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

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

2. **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.

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

4. **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.

5. **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()` <br> *Class: seq_ttest_arguments*    | `check_formula()`                            |                       |
|      | `extract_formula()`                          |                       |
|                                  | `get_one_sample()`                           |                       |
|                                  | `delete_na()`                                |                       |
|                                  | `check_data()`                               | `check_constant_data()` |
| `calc_seq_ttest()` <br> *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()` <br> *Class: seq_anova_arguments*  | `check_formula_anova()`|
|                                  | `extract_formula_anova()`                    |
|                                  | `check_data_anova()`                         |
| `calc_seq_anova()` <br> *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()` <br> *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