In an effort to investigate using underscores “consistently” (as we’ll see, this is hard to pin down), I made a list of all lowercase exports from Base:
It splits every lowercase base export wherever you could possibly argue that there’s a word break. The first observation is that if we used underscores between all of these, it would be pretty awful. If we don’t go all the way and use underscores everywhere, then we start having to draw a line between what gets underscores and what doesn’t. Depending on how we do that, it would throw away the familiarity that many of these names have since they come from C, Matlab, Python, etc. which arguably makes things harder to remember the spelling of, rather than easier. The current policy of avoiding underscores altogether goes in the complete opposite direction, but it does avoid the difficult and subjective task of deciding what separations get underscores and which don’t. Instead, it forces us to try to keep all the names as short and atomic as we can so that they’re readable.
On the other hand, most user code bases are not like a language standard library:
- They don’t have well-known, familiar names that are derived from other systems.
- They don’t have as strong a need to expose only atomic and indivisible concepts.
This is why I’ve suggested that Base continue to avoid underscores, while packages are encouraged to use underscores consistently if they contain lots of longish compound terms – as your library seems to.