Updated Coding Style (markdown)

Elad Ashkenazi 2023-07-23 19:34:24 +03:00
parent c265b76204
commit c2e3f88862
1 changed files with 11 additions and 5 deletions

@ -10,23 +10,27 @@ We recommend to follow these guidelines when writing code for RPCS3. They aren't
* Avoid `#defines`, use constant variables instead.
* Put curly-brackets (`{` and `}`) on the next line.
* Try to eliminate all compiler warnings from your code.
* Try to use C++ standard data types whenever it's possible (e.g. _std::string_ instead of _wxString_).
* Try to use C++ standard data types whenever it's possible (e.g. _std::string_ instead of _QString_).
* Comment *every* hack you do, *every* snippet you comment out and *every* improvable code.
* If you have to comment or place a commented code snippet, include the reasons to do that in the comment.
* Don't use `/**/` for commenting out multiple lines. Use `//` on every line instead. In Visual Studio, for example, you can just select desired lines and use `Ctrl+K,C` combination to comment every line with `//`, `Ctrl+K,U` reverts this.
* Ensure that every source file you modify has the newline at the end of file. Every line ends with "newline" and the end of file must have "newline" too, GitHub usually warns about it.
* Use brackets around multi-term ternary operator conditions especially if they occur with other code on the same line. `(x * y) + ((a > b)? c : d)` is more readable than `x * y + a > b? c : d`.
* Use `ensure()` and `fmt::throw_exception()` in order to add asserts in your code.
***
### Emulator coding style
* Module functions and lv2 syscalls:
* Access files converting path with `vfs::get` function.
* Return defined error codes. That is, use `return CELL_OK;` instead of `return 0;`.
* Prefer the type `error_code` as the return value instead of `int` or `s32`. (capable of reporting errors)
* Use `named_thread` instead of `std::thread`. To join it, call `named_thread::operator()()`.
* Use `g_fxo` for managing globally available variables for emulation, each variable must have a unique type.
* Use only limited number of types as function arguments and result types.
* Use `s8`, `s16`, `s32`, `s64` for signed integral types. These are aliases to `std::int8_t`, `std::int16_t`, `std::int32_t`, `std::int64_t` respectively.
* Use `u8`, `u16`, `u32`, `u64` for unsigned integral types. These are aliases to `std::uint8_t`, `std::uint16_t`, `std::uint32_t`, `std::uint64_t` respectively.
* Use `s8`, `s16`, `s32`, `s64` for signed integral types. These are aliases to `std::int8_t`, `std::int16_t`, `std::int32_t`, `std::int64_t` respectively. `s128` has been recently added and is a 128-bit signed integer.
* Use `u8`, `u16`, `u32`, `u64` for unsigned integral types. These are aliases to `std::uint8_t`, `std::uint16_t`, `std::uint32_t`, `std::uint64_t` respectively. `u128` has been recently added and is a 128-bit unsigned integer.
* Use `f32` and `f64` for floating point numbers. These are aliases to `float` and `double`.
* Use `b8` instead of `bool`. This type is special.
* Use `b8` instead of `bool`. This type is a fixed 8-bit boolean-mimicking type.
* Use `char` for UTF-8 string characters, usually as `vm::cptr<char>`. Don't treat char values as signed or unsigned numbers.
* Function arguments and results use native endianness.
* Use `vm::ptr<>` arguments for PS3 memory pointers.
@ -37,7 +41,9 @@ We recommend to follow these guidelines when writing code for RPCS3. They aren't
* Note that types `vm::ptr<u32>` and `vm::ptr<be_t<u32>>` are equal, because `be_t<>` template is implicitly applied in `vm::ptr<>` for basic types. You always work with big endian values in ps3 virtual memory, excepting some very rare cases.
* Usual pointers (`vm::ptr`) are native-endian itself, but don't forget that dereferencing vm::ptr leads to the PS3 memory which uses big-endian values by default (if it's not known explicitly that some specific value is little-endian).
* Pointers in PS3 memory must be big-endian: define them as `vm::bptr` or `vm::bcptr`.
* Allocate memory for temporary variables with `vm::var<>`. Under construction.
* Allocate memory for temporary variables with `vm::var<>` (RAII based). It has similar semantics to `vm::ptr<>`.
* Because it is RAII based, prefer to use it as lvalue, do not leak its freed address by doing something like: `vm::ptr<u32> _u32 = vm::var<u32>{};`
* Use `vm::gvar<>` to allocate memory to be used globally.
* Don't forget logging at the top of every function. Print all its arguments with `%d` or `0x%x` (always use `0x%x` if not sure).
* Don't forget `0x` in `0x%x`. It may be really confusing.
* Use `moduleName.todo()` and other associated methods.