I would tend to agree. It's certainly a generally good rule of thumb. However, I've honestly struggled to find a way to document the naming conventions that is useful. Every time I've wondered about a particular name, it's faster for me to go to the definition sight of that name than to seek documentation, and the documentation for the naming conventions might exceed the size of most of the compiler, simply because it's hard to write out all of the aesthetic and stylistic choices that are almost self enforcing through an overwhelming pressure of context when you're actually programming in the code. Basically, while I am a huge fan of documentation, with this style and the approach I'm taking, I've found it exceptionally difficult to create up to date, meaningful, and reliable documentation of any sort that isn't totally useless. Now, I do have public API documentation, but internal developer docs have not proven to be helpful at all for any reason in this compiler. I've tried on multiple occasions to make it happen, and it just doesn't work here. If you have a way to do so, or even maybe if you want to talk with me and make it happen, all the better, but when the code base changes so fast all the time, it's just very hard to keep documenting this fluid thing that keeps changing. In some ways that includes the naming conventions.

I'm quite open to people providing ideas on how to properly document this project outside of "big idea" documentation that I'm currently doing with the paper publications. I've yet to be able to find anything that works. The standard best practices don't seem to flow well at all, but maybe I've missed something.