emscripten-core / emscripten-core/emscripten
Clarify and document naming convention used in our client side JS (library and support code).
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
Ideally this would also allow is to mark certain APIs as non-public.
Currently I believe the status quo is something like this:
"Native" functions
------------------------
We use `snake_case` for implement native functions in JavaScript. The functions are callable from native code and take only basic number types as arguments (wasm types). These functions are callable form JS using the `_` prefix in the same that that native functions are callable from JS using the `_` prefix. So `foo_bar` in the native world is the same `foo_bar` in the JS library world in that it needs to be called as `_foo_bar`.
JS Support Functions
-----------------------------
We use `camelCase` for JS functions. These are functions that take JS objects as arguments are therefore make no sense to be callable from native code directly. We use the `$` prefix when declaring these function in the library files to prevent them from be callable/visible from native code.
Internal APIs
-----------------
We also have some places were we seem to use `_` or `__` with JS functions (and native functions) to mark them are internal (not to be directly called by user code). It would be useful to formalize this so that we know which parts of our library JS code we can modify/remove with impunity.
Contributor guide
Assessment
This issue has not been assessed yet.