mirror of
https://github.com/hedge-dev/UnleashedRecomp.git
synced 2026-01-01 01:01:19 -06:00
47 lines
4.0 KiB
Markdown
47 lines
4.0 KiB
Markdown
# SWA
|
|
|
|
## Contribution Guide
|
|
|
|
### Naming Conventions
|
|
|
|
- Use `camelCase` for local variables, `SNAKE_CASE` for preprocessor macros, and `PascalCase` for everything else. SWA-specific types that don't exist in the game should use `snake_case` for better differentiation.
|
|
- Class names should be prefixed with `C`, e.g., `CSonicContext`.
|
|
- Struct names should be prefixed with `S`, e.g., `SUpdateInfo`.
|
|
- Class members should be prefixed with `m_`, e.g., `m_Time`. Do not use this prefix for struct members.
|
|
- Enum names should be prefixed with `E`, e.g., `ELightType`.
|
|
- Enum members should start with `e`, followed by the enum name and an underscore, e.g., `eLightType_Point`.
|
|
- For enum members indicating the count of elements, prefix with `n`, followed by the name, e.g., `nLightType`.
|
|
- Pointers should be prefixed with `p`, e.g., `pSonicContext`.
|
|
- Shared pointers should be prefixed with `sp`, e.g., `spDatabase`.
|
|
- References should be prefixed with `r`, e.g., `rMessage`.
|
|
- Input function arguments should be prefixed with `in_`, e.g., `in_Name`.
|
|
- Output function arguments should be prefixed with `out_`, e.g., `out_Value`.
|
|
- Static class members should be prefixed with `ms_`, e.g., `ms_Instance`.
|
|
- Static members outside a class should be prefixed with `g_`, e.g., `g_AllocationTracker`.
|
|
- SWA-specific preprocessor macros should start with `SWA_`, e.g., `SWA_INSERT_PADDING`.
|
|
- Hedgehog namespace-specific preprocessor macros should start with `HH_` along with the library's shorthand, e.g., `HH_FND_MSG_MAKE_TYPE`.
|
|
- Function pointers should be prefixed with `fp`, e.g., `fpCGameObjectConstructor`.
|
|
|
|
Combine prefixes as necessary, e.g., `m_sp` for a shared pointer as a class member or `in_r` for a const reference as a function argument.
|
|
|
|
### Coding Style
|
|
|
|
- Always place curly brackets on a new line.
|
|
- Prefer forward declaring types over including their respective headers.
|
|
- Use <> includes relative to the project's root directory path.
|
|
- Use C++17's nested namespace feature instead of defining multiple namespaces on separate lines.
|
|
- Enum classes are prohibited as they were not available when the game was developed.
|
|
- Avoid placing function definitions in .h files, instead, implement functions in the header's respective .inl file, similar to a .cpp file.
|
|
- Ensure that all class members are declared as public. Even if you suspect that a class member was private in the original code, having it public is more convenient in a modding API.
|
|
- Avoid placing multiple class definitions in a single header file unless you have a good reason to do so.
|
|
- Keep function pointers or addresses outside functions, define them as global variables in the corresponding .inl file. Mark these global variables as `inline` and never nest them within class definitions. You do not need to use the `g_` prefix for function pointers, `fp` is sufficient.
|
|
- Use primitive types defined in `cstdint` instead of using types that come with the language, e.g., use `uint32_t` instead of `unsigned int`. Using `float`, `double` and `bool` is okay.
|
|
|
|
### Mapping Rules
|
|
|
|
- Always include the corresponding `offsetof`/`sizeof` assertions for mapped classes/structs. If you are uncertain about the type's size, you can omit the `sizeof` assertion.
|
|
- Use the exact type name from the game if it's available through RTTI, otherwise, you can look for shared pointers that may reveal the original type name.
|
|
- If you are unsure about the name of a class/struct member, use `Field` followed by the hexadecimal byte offset (e.g., `m_Field194`). Avoid names like `m_StoresThisThingMaybe`, you can write comments next to the definition for speculations.
|
|
- If a portion of the byte range is irrelevant to your research or not mapped yet, use the `SWA_INSERT_PADDING` macro to align class/struct members correctly.
|
|
- When the class has a virtual function table, if you don't want to map every function in it, you can map only the virtual destructor.
|
|
- The original file locations are likely available in the executable file as assertion file paths. If you cannot find the file path, use your intuition to place the file in a sensible place. |