if the documentation of a class just has a table of function params and return types without any example snippets of how to use them, fuck you and your entire stack and your entire docs.

I feel you. Yet, it's better than nothing at all

@netikras No, it‘s worse than nothing at all. Because now there is a chance that this "documentation" is not up to date. And still provides 0 value. Negative value actually.

@Lensflare aren't these auto-generated when the project is built?

@netikras could be. Wouldn't make it better though. Yes, they would be up to date but they wouldn't provide any value besides "this class exists" and "this method exists".

@Lensflare Depends, really. Sometimes that's exactly the piece of info you're short on. Decompilers tend to assign made-up names to parameters, methods; variables' names. Having at least the first two labeled in a readable manner (i.e. docs with sensible method names and param names) could save from days of rev-engineering.

Been there. Done that.

@netikras I don‘t get your use case. If you need to know what stuff exists in a library, then you can get it directly from the public interfaces. Anything that is not public is not accessible anyway and is irrelevant for the usage of that library.
If you need to get your info from decompilation and reverse engineering then you can‘t demand documentation obviously, because it is purposely undocumented.

@Lensflare exactly. I'm not demanding. Instead, I'm glad it exists, even in minimal format.

Twice or thrice I ran into this: an app is a bag of absolute legacy stuff - some of the deps not even available in pub repos [only from a local cache]. Meaning source packages are unavailable too. Intellisense refuses to work properly. And the only usage docs I can find is an autogenerated javadoc in some polish website.

And at the last you should add fuck yourself 🤣🤣🤣