SSXModding
/
ssxog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
.clang-format
View File

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

15
cmake/Toolchain/ps2.cmake
View File

@ -13,20 +13,23 @@ list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}")
# C/C++ compiler # C/C++ compiler
set(CMAKE_C_COMPILER ee-gcc) set(CMAKE_C_COMPILER $ENV{SCE}/ee/gcc/bin/ee-gcc)
set(CMAKE_CXX_COMPILER ee-g++) set(CMAKE_CXX_COMPILER $ENV{SCE}/ee/gcc/bin/ee-g++)
# We can't use the compiler generated dependency files, # We can't use the compiler generated dependency files,
# since it adds flags GCC 2.9 doesn't understand. # since it adds flags GCC 2.9 doesn't understand.
# While it understands -MD, it does not understand -MD or -MF, # While it understands -MD, it does not understand -MT or -MF,
# which causes the build to fail. # 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_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_C_FLAGS_RELEASE_INIT "${CMAKE_C_FLAGS_INIT}")
set(CMAKE_CXX_FLAGS_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}") set(CMAKE_CXX_FLAGS_RELEASE_INIT "${CMAKE_C_FLAGS_RELEASE_INIT} ${CMAKE_CXX_FLAGS_INIT}")
set(CMAKE_EXE_LINKER_FLAGS_INIT " -L$ENV{SCE}/ee/lib -mno-crt0 -T $ENV{SCE}/ee/lib/app.cmd") set(CMAKE_EXE_LINKER_FLAGS_INIT " -L$ENV{SCE}/ee/lib -mno-crt0 -T $ENV{SCE}/ee/lib/app.cmd")
set(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "") set(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "")

102
docs/styleguide.md
View File

@ -1,12 +1,14 @@
# SSX Decompilation Style Guide # 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 # Code Style
## Braces/Indentation ## 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 ```cpp
if(1) if(1)
@ -25,60 +27,48 @@ catch(...)
Tabs are used for indentation throughout the codebase. 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 ## Naming Rules
### Variables ### 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 | | Name | Meaning/Scenario |
| -------- | ---------------------------------------------- | |------|-------------------------------------------|
| `b` | byte (unsigned char, don't do `uc`) | | `m` | Class member (or static member) variable. |
| `c` | char | | `g` | Global variable. |
| `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. |
### Types ### 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 |
|--------|-------------------------------------------------|
| `t` | `typedef struct` |
| `c` | `class/struct` |
| `T` | `template<> class/struct` (* Only seen in SSX3) |
| Prefix | C++ Type 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).
| -------- | ------------------------------------------------ |
| `t` | `typedef struct` |
| `c` | `class` |
| `T` | `template<> class/struct` (* Only seen in SSX3) |
### Pointer/Reference Types ### 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 ### Functions
Function naming is PascalCase wherever possible, except for legacy code (specifically SND & REAL). 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. 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 ## 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 ```cpp
// A basic object. // A basic object.
class cBxObject class cBxObject
{ {
public: public:
int miCounter; int mCounter;
static int miVar; static int mVar;
uint32_t muiUnsignedValue;
uint32_t mUnsignedValue;
uint16_t musShort; uint16_t mShort;
int16_t msSignedShort; int16_t mSignedShort;
static uint16_t musStaticValue; static uint16_t mStaticValue;
static int16_t msStaticSignedValue; static int16_t mStaticSignedValue;
int *mpiVar; uint64_t mThing;
int64_t mSignedThing;
static int64_t mThingStatic;
static uint64_t mThingStatic;
int* mPointerVar;
// Morph // Morph
void 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 typedef struct
{ {
int iNumber; int Number;
void DoIt();
} tBxStructure; } tBxStructure;
// example of a legacy function and type name // example of a legacy function and type name
@ -128,8 +124,8 @@ FILEOP *FILE_dothing();
void cBxObject::Morph() void cBxObject::Morph()
{ {
miCounter++; mCounter++;
if(miCounter == 32) if(mCounter == 32)
{ {
// Do something important. // Do something important.
} }

4
src/bx/CMakeLists.txt
View File

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

6
src/bx/main.cpp
View File

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