134 lines
3.1 KiB
Markdown
134 lines
3.1 KiB
Markdown
# SSX Decompilation Style Guide
|
|
|
|
Most of the documentation here is enforced by [clang-format](https://clang.llvm.org/docs/ClangFormat.html).
|
|
|
|
However, I've written other naming rules which aren't enforced down to make it more obvious, and to aid potentional contributors.
|
|
|
|
# Code Style
|
|
|
|
## Braces/Indentation
|
|
|
|
Any block scopes should have the brace on the next line, ala Allman bracing.
|
|
|
|
```cpp
|
|
if(1)
|
|
{
|
|
// do something
|
|
}
|
|
|
|
try
|
|
{
|
|
}
|
|
catch(...)
|
|
{
|
|
// An error occured
|
|
}
|
|
```
|
|
|
|
Tabs are used for indentation throughout the codebase.
|
|
|
|
## East/West Const/Volatile/...
|
|
|
|
It seems EA preferred west-const (where semantically possible), so, go west, collect 200$, get out of jail.
|
|
|
|
## Naming Rules
|
|
|
|
### Variables
|
|
|
|
Variable naming is not too complicated; just try to make it understandable.
|
|
|
|
There are the following special prefixes, used in certain scenarios:
|
|
|
|
| Name | Meaning/Scenario |
|
|
|------|-------------------------------------------|
|
|
| `m` | Class member (or static member) variable. |
|
|
| `g` | Global variable. |
|
|
|
|
### Types
|
|
|
|
BX/SSX types have a prefix before them, which is:
|
|
|
|
| Prefix | C++ Type |
|
|
|--------|-------------------------------------------------|
|
|
| `t` | `typedef struct` |
|
|
| `c` | `class/struct` |
|
|
| `T` | `template<> class/struct` (* Only seen in SSX3) |
|
|
|
|
Legacy types (REAL/SND) won't/don't need this due diligence, so it's ok to omit with those (as a matter of fact, it'd be more correct).
|
|
|
|
### Pointer/Reference Types
|
|
|
|
The pointer/reference goes on the side of the type, ala `T* name` and `T& name`.
|
|
|
|
### Functions
|
|
|
|
Function naming is PascalCase wherever possible, except for legacy code (specifically SND & REAL).
|
|
|
|
In this case, REAL/SND functions follow the following standard:
|
|
|
|
`[component/namespace, as uppercase]_[lowercase function name]`.
|
|
|
|
No functions should be annotated as `(void)` unless explicitly decompiled as C or exported in a C header file, as C++ ensures `()` is not surprising.
|
|
|
|
Member functions can use the longer `this->` access pattern for members if desired, but you don't have to unless you.. well, *have* to.
|
|
|
|
## Comments
|
|
|
|
Don't really care. If you think something might not be obvious, feel free to comment describing it.
|
|
|
|
If there's something surprising (or repulsive, considering 2000 C++), do so too.
|
|
|
|
## Example
|
|
|
|
Provided is an example of code fitting the style guide, to hopefully visualize things better.
|
|
|
|
```cpp
|
|
// A basic object.
|
|
class cBxObject
|
|
{
|
|
public:
|
|
int mCounter;
|
|
static int mVar;
|
|
|
|
uint32_t mUnsignedValue;
|
|
|
|
uint16_t mShort;
|
|
int16_t mSignedShort;
|
|
|
|
static uint16_t mStaticValue;
|
|
static int16_t mStaticSignedValue;
|
|
|
|
uint64_t mThing;
|
|
int64_t mSignedThing;
|
|
|
|
static int64_t mThingStatic;
|
|
static uint64_t mThingStatic;
|
|
|
|
int* mPointerVar;
|
|
|
|
// Morph
|
|
void Morph();
|
|
|
|
void ReferenceExample(int& output); // only for reference output
|
|
};
|
|
|
|
typedef struct
|
|
{
|
|
int Number;
|
|
|
|
void DoIt();
|
|
} tBxStructure;
|
|
|
|
// example of a legacy function and type name
|
|
FILEOP *FILE_dothing();
|
|
|
|
void cBxObject::Morph()
|
|
{
|
|
mCounter++;
|
|
if(mCounter == 32)
|
|
{
|
|
// Do something important.
|
|
}
|
|
}
|
|
```
|