Coding Style updated (written by NekotekinaHito)

Coding-Style.md

@@ -15,15 +15,36 @@ We recommend to follow these guidelines when writing code for RPCS3. They aren't
 
 ***
 ### Emulator coding style
-* Module functions and lv2 SysCalls:
+* Module functions and lv2 syscalls:
     * Handle file accesses using *VFS* functions.
     * Return defined error codes. That is, use `return CELL_OK;` instead of `return 0;`.
     * Do **not** delete the entries in *rpcs3/Emu/SysCalls/FuncList.cpp* after implenting a function.
-* Use `mem*_t` arguments instead of `u32 *_addr`.
-    * Pointers to `u8`, `u16`, `u32`, `u64` are respectively `mem8_t`, `mem16_t`, `mem32_t`, `mem64_t`.
-    * Pointers to the datatype `T` are `mem_ptr_t<T>`.
-    * Pointers to the function `T (*)(t1 a1, t2 a2)` are `mem_func_ptr_t<T (*)(t1 a1, t2 a2)>`
-* Allocate memory with *MemoryAllocator*.
-    * Don't forget to switch endianness: That is, allocate `u32` with `MemoryAllocator<be_t<u32>>`
+* Use only limited number of types in function arguments and result type.
+    * Use `s8`, `s16`, `s32`, `s64` for integral signed types.
+    * Use `u8`, `u16`, `u32`, `u64` for unsigned types.
+    * Use `float`, `double` for floating point numbers.
+    * Use `bool` as is; `char` for representing UTF-8 string character.
+    * Don't use `be_t<>` in function arguments/results, they are already little-endian.
+    * But don't forget that dereferencing vm::ptr for PS3 leads to big-endian values.
+* Use `vm::ptr<>` arguments instead of `pointers`.
+    * Pointers to the datatype `T` are `vm::ptr<T>`. For example, `void *buf` becomes `vm::ptr<void> buf`.
+    * Pointers to the datatype `const T` are `vm::ptr<const T>`. For example, `const char *path` becomes `vm::ptr<const char> path`.
+    * Pointers to the function `T(T1 arg1, ...)` are `vm::ptr<T(T1 arg1, ...)>`.
+    * The function may be defined as `typedef T(func_name)(T1 arg1, ...);`, which becomes `vm::ptr<func_name>`.
+    * Notice that `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.
+* Allocate memory for temporary variables with *vm::var<>* or *vm::stackvar<>*.
+    * Don't forget to switch endianness: That is, allocate `u32` with `vm::stackvar<be_t<u32>>`
 * Switch endianness of constants on compile time if possible:
-    * When comparing `be_t<u32> x` with the constant `y`, use: `x.ToBE()` and `se32(y)` respectively to gain speed by switching endianness on `y` in compilation time.
+    * When comparing `be_t<u32> x` with the constant `y`, use: `x.data()` and `se32(y)` respectively to gain speed by switching endianness on `y` in compilation time.
+    * `be_t<>.data()` method always returns the value of unsigned integer type (u16, u32, u64), as `se16()`, `se32()`, `se64()` do.
+    * You are not forced to do it, especially if it decreases readability too much or you are not sure.
+    * You can safely use only limited number of operations on raw big endian `.data()` or `se**()`: comparison with zero, logical bitwise `&`, `|`, `^` and `~`.
+* 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.
+    * Use `.Todo()` method for unimplemented functions.
+    * Use `.Error()` method to print error inside of function that may require user's attention. For example, some file is not found or some emulation option is not set correctly.
+    * Use `.Warning()` method for partially implemented functions which still have some unimplemented functionality.
+    * Use `.Notice()` method to print debug information unconditionally.
+    * Use `.Log()` method for well implemented functions.
+    * Don't return CELL_OK and other error codes if the function result type doesn't mean error code.