I use lack of ambiguity as a measure of documentation quality. The best (honestly the only good) documentation that I've ever found is at:

https://www.php.net/<keyword>

For example:

https://www.php.net/echo

Note how even this simple arbitrary example tells us "No additional newline is appended." It's shocking to me how many other guides would leave something that critical out of the manual.

Then there are even helpful examples beneath that showcase users' experiences and any errata that they've discovered.

Contrast this with Ruby's manual:

https://docs.ruby-lang.org/en/master/ARGF.html#method-i-prin...

I can infer that to_s is probably to_string. But I'm already hit with several new concepts like $, $_ and $\ which aren't clickable, so now it requires work to track down what they mean. The related methods beneath (like puts) are similarly cryptic. A good percentage of the time in search engine results, I click both the Ruby documentation and Stack Overflow links.

I don't remember ever really learning PHP, because I realized quickly into it that it was a thin wrapper fixing any operating system shortfalls, generally leveraging concepts and contextual cues from C, C++ and the shell. Meanwhile Ruby had one of the steepest learning curves I've ever encountered outside of functional programming, even though it's similarly based on Perl and the shell.

So where Ruby is a "convention over configuration" language, PHP is more of an "existing context over surprises" language.

Writing the documentation for a language or framework can reveal these surprises, and over time, improve the tech itself and lead to a better experience.