Update style guide and clang-format file

This commit is contained in:
Lily Tsuru 2022-06-26 16:24:21 -05:00
parent 9140d36820
commit b747dd5e2e
6 changed files with 92 additions and 67 deletions

View File

@ -1,14 +1,19 @@
BasedOnStyle: WebKit
# :( This is most of the style, tbh.
# This is most of the style, tbh.
BreakBeforeBraces: Allman
DerivePointerAlignment: false
PointerAlignment: Right
# :)
PointerAlignment: Left
TabWidth: 4
IndentWidth: 4
UseTab: Always
# They may not have done this, but by god, I am.
NamespaceIndentation: All
AllowShortBlocksOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None

View File

@ -13,16 +13,19 @@ list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}")
# C/C++ compiler
set(CMAKE_C_COMPILER ee-gcc)
set(CMAKE_CXX_COMPILER ee-g++)
set(CMAKE_C_COMPILER $ENV{SCE}/ee/gcc/bin/ee-gcc)
set(CMAKE_CXX_COMPILER $ENV{SCE}/ee/gcc/bin/ee-g++)
# We can't use the compiler generated dependency files,
# since it adds flags GCC 2.9 doesn't understand.
# While it understands -MD, it does not understand -MD or -MF,
# which causes the build to fail.
# While it understands -MD, it does not understand -MT or -MF,
# which causes the actual build to end up failing.
#
# This option is only obeyed with the Makefile generator,
# which is why Ninja cannot be used.
set(CMAKE_DEPENDS_USE_COMPILER OFF)
set(CMAKE_C_FLAGS_INIT "-I$ENV{SCE}/ee/include -I$ENV{SCE}/common/include -DPLATFORM_PS2 -DPS2_SONYSDK -fno-exceptions -fno-common")
set(CMAKE_C_FLAGS_INIT "-I$ENV{SCE}/ee/include -I$ENV{SCE}/common/include -DBX_PLATFORM_PS2 -DBX_PS2_SONYSDK -fno-exceptions -fno-common")
set(CMAKE_C_FLAGS_RELEASE_INIT "${CMAKE_C_FLAGS_INIT}")
set(CMAKE_CXX_FLAGS_INIT "${CMAKE_C_FLAGS_INIT}")
set(CMAKE_CXX_FLAGS_RELEASE_INIT "${CMAKE_C_FLAGS_RELEASE_INIT} ${CMAKE_CXX_FLAGS_INIT}")

View File

@ -1,12 +1,14 @@
# 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 things down to make it more obvious.
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, like so:
Any block scopes should have the brace on the next line, ala Allman bracing.
```cpp
if(1)
@ -25,60 +27,48 @@ catch(...)
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 names should loosely follow Hungarian Notation.
Variable naming is not too complicated; just try to make it understandable.
For quick reference:
There are the following special prefixes, used in certain scenarios:
| Prefix | Type |
| -------- | ---------------------------------------------- |
| `b` | byte (unsigned char, don't do `uc`) |
| `c` | char |
| `u` | Unsigned (prefixed before `i` or `s`) |
| `s` | Short |
| `i` | Integer |
| `p` | Pointer to (add for every \*) |
| `v` | `void`; should only ever be used for pointers |
| `sz` | Null terminated string |
| `fl` | Float |
| `d` | Double |
Enumerations or structures do not need special notations; naming of variables should be enough (pointers should only need `p`).
Additionally, there are also the following special prefixes:
| Name | Meaning |
| ------- | --------------------------------------- |
| `m` | Class member variable. |
| Name | Meaning/Scenario |
|------|-------------------------------------------|
| `m` | Class member (or static member) variable. |
| `g` | Global variable. |
### Types
Types have a prefix before them.
BX/SSX types have a prefix before them, which is:
Legacy types (REAL/SND) won't need this due diligence, so it's ok to omit with those (as a matter of fact, it'd be more correct).
| Prefix | C++ Type
| -------- | ------------------------------------------------ |
| Prefix | C++ Type |
|--------|-------------------------------------------------|
| `t` | `typedef struct` |
| `c` | `class` |
| `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 name, ala `T *name` and `T &name`.
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 functions follow the following standard:
In this case, REAL/SND functions follow the following standard:
`[component as uppercase]_[lowercase name]`.
`[component/namespace, as uppercase]_[lowercase function name]`.
No functions should be annotated as `(void)` unless explicitly decompiled as C , as C++ ensures `()` is not surprising.
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.
@ -90,37 +80,43 @@ If there's something surprising (or repulsive, considering 2000 C++), do so too.
## Example
Provided is an example of the code style guide, to hopefully visualize things better.
Provided is an example of code fitting the style guide, to hopefully visualize things better.
```cpp
// A basic object.
class cBxObject
{
public:
int miCounter;
static int miVar;
uint32_t muiUnsignedValue;
int mCounter;
static int mVar;
uint16_t musShort;
int16_t msSignedShort;
uint32_t mUnsignedValue;
static uint16_t musStaticValue;
static int16_t msStaticSignedValue;
uint16_t mShort;
int16_t mSignedShort;
int *mpiVar;
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 &iOutput); // only for reference output
void ReferenceExample(int& output); // only for reference output
};
// TODO: probably won't advocate for this unless
// I have to since structs are types in C++
typedef struct
{
int iNumber;
int Number;
void DoIt();
} tBxStructure;
// example of a legacy function and type name
@ -128,8 +124,8 @@ FILEOP *FILE_dothing();
void cBxObject::Morph()
{
miCounter++;
if(miCounter == 32)
mCounter++;
if(mCounter == 32)
{
// Do something important.
}

View File

@ -1,8 +1,4 @@
add_executable(ssx
# TODO: seperate this into another target_sources(ssx) call later
$ENV{SCE}/ee/lib/crt0.s
main.cpp
)

23
src/bx/Utils.h Normal file
View File

@ -0,0 +1,23 @@
#ifndef SSXOG_UTILS_H
#define SSXOG_UTILS_H
// Use REAL to allocate an object.
// Insert into a class body like so:
//
// class cExample
// {
// public:
// BX_REAL_ALLOC("Example", MB_LOW); // `new cExample()` will use REAL to allocate the class instead of standard malloc
// };
#define BX_REAL_ALLOC(name, flags) \
inline void* operator new(size_t size) \
{ \
return MEM_alloc(name, size, flags); \
} \
\
inline void operator delete(void* object) \
{ \
MEM_free(object); \
}
#endif // SSXOG_UTILS_H

View File

@ -2,7 +2,9 @@
// will be replaced with real code later
#include <stdio.h>
int main()
int main(int argc, char** argv)
{
printf("Hello World!\n");
printf("meow\n");
void* a = nullptr;
}