Hi, I have no idea why unity didn’t make documentation for UnityEditorInternal.
I’m looking for the documentation for UnityEditorInternal. Thanks
As I understand it developers aren’t supposed to use UnityEditorInternal. It will be documented, but only internally for use by Unity staff.
Use at your own risk, there is no guareentee it won’t change randomly on an update.
If you’re specifically looking for documentation on UnityEditorInternal.ReorderableList, Valentin Simonov wrote a good article: Unity: make your lists functional with ReorderableList
(But still bear in mind BoredMormon’s advice; use at your own risk.)
1 Like
Thanks for your answer guys.
for reference, can browse here (5.4 version), easier to have a look,
https://github.com/MattRix/UnityDecompiled/tree/master/UnityEditor/UnityEditorInternal
*update 2018,
3 Likes
Wow ! Precious treasure ! 
I actually don’t know why there is not documentation on everything developers “CAN” use? No offense, but I just found out that it IS possible to alter the order of VR SDKs via code, which I needed for my build pipeline, but instead of documenting this I had to use google to find someone who found the API for it. This is one of a number of unnecessary hurdles.
Please be more “you’re good developers and know what you’re doing, we give you guns” instead of “here’s your rubber mallet, but be careful with it”
Writing good documentations is about as hard as writing the good API. Having documented everything like in MSDN or man pages would double unity pro subscription price, that’s why )
1 Like
A public API is like a promise that the API will stay more or less stable. I think the idea behind the internal stuff is that it’s not for public use, and it’s not guaranteed to remain the same between versions. Since it’s internal, Unity has no obligation to support it.
That said, there are some things that everyone uses anyway, such as ReorderableList, that would cause major issues if Unity were to remove it or change it.
I’m not even sure doubling the price would be effective. Since each piece of documentation can be viewed as a promise for consistent behaviour, as much as information to the developers using it, you can’t really half-ass it / have new blood writing it. You need the author, or at least someone intimately familiar with its inner workings and effects. It would also make new versions increasingly difficult to make, as they’d have to tip-toe around all of those additional promises, all for functionality 99% of devs don’t even need to know about or use directly.