Naming conventions?

[ddsjoberg]

Have you considered a naming convention for these function?

Some ideas:

• since the package begins with ci and all these functions are for calculating CIs, perhaps all the functions could begin with ci_*()
• then we have a grouping for type of CI, e.g. CIs for proportions, CIs for proportion differences, CIs for odds ratios, etc. For each of these groupings, we could include the group name, e.g.
  • ci_proportion_*()
  • ci_proportion_diff_*()
  • ci_odds_ratio_*()
• we could finish it off with the method description, e.g. ci_odds_ratio_boschloo()
• Since they all begin with ci_*() we could also drop the ci prefix

Results Naming!
I like the idea that each of these functions return a named list to keep it simple. We can, of course, add a print method to print them cuter, but an simple underlying structure would be great. I also like the idea of using the naming conventions from broom::tidy() (see example below). It's lovely having consistent names internally and externally.

In addition to returning the bits below, I would also like to see conf.level and n and N (where the estimate is n / N).

with(mtcars, prop.test(x = sum(am), n = length(am))) |> broom::tidy() |> as.list()
#> $estimate
#>       p 
#> 0.40625 
#> 
#> $statistic
#> X-squared 
#>   0.78125 
#> 
#> $p.value
#> [1] 0.3767591
#> 
#> $parameter
#> df 
#>  1 
#> 
#> $conf.low
#> [1] 0.2421914
#> 
#> $conf.high
#> [1] 0.5921457
#> 
#> $method
#> [1] "1-sample proportions test with continuity correction"
#> 
#> $alternative
#> [1] "two.sided"

^{Created on 2025-04-29 with reprex v2.1.1}

Anyway, looking forward to getting started!

[statasaurus]

I can't decide if there should be a separate function for each method. Some methods like the mn score method just the score from the mee method. I know that is just a backend thing but still. I like the ci_* plan

[ddsjoberg]

There are merits to both ways for sure!

The one thing I am hesitant about for one function with a method argument, is that various methods require different inputs, so our one function will end up having many arguments, when most of those arguments only apply to one method. Even an argument like correct can be confusing, because it may only apply to handful of methods and it's difficult to signal to users which arguments are being ignored and which are not.

[statasaurus]

We agreed:

ci_prop_*
ci_prop_diff_*
ci_odd_ratio_*

separate functions for each function, same function for same method stratified and non-stratified, correct and non-corrected

[statasaurus]

have s3 vector methods and default and data.frame methods