覆盖R包中全局选项的合法原因？

我只是在GitHub上随机探索了一个相对较新且较小的R包，我看到的第一件事就是

选项（scipen=999）

这给我敲响了警钟。他们多次这样做，包括

选项（stringsAsFactors=FALSE）

它困扰我的原因是，它可能会导致用户出现意外且难以调试的行为，特别是对于像read.csv（）这样的常见函数，其中有些人可能依赖默认为因子的字符串

> dat = read.csv("a.csv")
> str(dat)
'data.frame':   2 obs. of  3 variables:
 $ a: int  1 2
 $ b: num  NA 3.5
 $ c: Factor w/ 2 levels "Hello","my": 1 2
> chg_saf = function() {
+   options(stringsAsFactors = FALSE)  
+ }
> chg_saf()
> dat = read.csv("a.csv")
> str(dat)
'data.frame':   2 obs. of  3 variables:
 $ a: int  1 2
 $ b: num  NA 3.5
 $ c: chr  "Hello" "my"

如果他们至少在函数结束时尝试恢复默认状态，可能不会让我太烦恼，但即使这样也会让我烦恼，因为由于错误而过早退出函数会阻止恢复状态（我实际上遇到了一个setwd有此问题的包…）

---

现在，我计划向他们的GitHub问题跟踪者提交一个问题，礼貌地要求他们不要这样做。但在此之前，它激起了我的好奇心在用户不知道的情况下覆盖R包中R的全局选项是否合适？

我认为没有有效的情况。。。但这是基于意见的。。。这是一个得到充分支持的观点，因为如果CRAN改变了全球环境，你就不会得到一个关于CRAN的包

on.exit（）。