• Self Explanatory

No need to learn anything to be able to use the library. Like you can close this documentation right now and start to use it.

• Non-Intrusive

Does not leave the developer with a feeling of having a bulky overwhelming library that complains a lot.

• Performant

Heavily used parts of the library are optimized. Does not slow down the Unity Editor. Presents tools for you to write optimized code.

• Lightweight

Only includes features that can be generalized to be used in masses, not specific to a small set of projects.

// TODO:

• No Backwards Compatibility

The library tries to support older versions of Unity but it's not the primary focus. So whenever a great opportunity arrives with a recent version of Unity and it's hard to support an implementation for both older and newer versions, the latter one wins.

• 'See' Referencing

Whenever there are correlated lines exist in different parts of codebase, those lines are marked with // See 11###### comments that includes a unique code for that topic. So that when a developer needs to take a look at those lines or need to modify those lines, the developer can jump between related lines just by searching this code in all codebase.

The code is generated by tapping keys randomly. All codes should start with 11 prefix, like See 11987654. That allows a full search via See 11. Make sure that when you generate a code, it does not collide with existing ones. Just searching the codebase for the generated code and seeing there is none will suffice.

• Error Handling

Error handling tasks are application specific. So the library tries not to interfere with error handling, like it does not try to correct errors and decide application behaviour.

That being said, there are these types of errors that are considered Internal Errors. These error are considered as they should not ever happen at all. In these cases, the library would throw InternalError exceptions, which means there is a problem at the library internals that should be fixed and should not tried to be handled at the application level. Internal Errors do not come with a message to inform the user. They only have a unique code to identify at which line the code went crazy. Best way to track internal errors is to have a Cloud system that tracks errors and exceptions that are happened in user devices.

The same idea can also be applied at the application level.