ShuriZma
/
pcsx2
mirror of https://github.com/PCSX2/pcsx2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

As we'd like to move away from wx at some point in future, no longer recommend using it in code that doesn't need it.

arcum42 2021-11-25 21:12:06 -08:00
parent d7bd144b63
commit 0becbf33e6
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Code-Formatting-Guidelines.md

@ -14,9 +14,9 @@ Besides being obscenely ugly, this naming convention is totally impractical for
**Just don't do it. _Ever._** **Just don't do it. _Ever._**
## Topic 2: Using PCSX2 and wxWidgets base types instead of C/C++ atomic types. ## Topic 2: Using PCSX2 base types instead of C/C++ atomic types.
Most of the time you want to use either PCSX2 or wxWidgets cross-platform types in the place of C++ atomic types. Most of the common types are: Most of the time you want to use either PCSX2 cross-platform types in the place of C++ atomic types. Most of the common types are:
```C++ ```C++
u8, s8, u16, s16, u32, s32, u64, s64, u128, s128, uptr, sptr u8, s8, u16, s16, u32, s32, u64, s64, u128, s128, uptr, sptr
``` ```
@ -26,6 +26,8 @@ Note that using the C++ atomic types `float` and `double` are acceptable, and th
**Special note:** PCSX2-specific types `uptr` and `sptr` are meant to be integer-typed containers for pointer addresses, and should be used in situations where pointer arithmetic is needed. `uptr/sptr` definitions are not type safe and `void*` or `u8*` should be used for parameter passing instead, when possible. **Special note:** PCSX2-specific types `uptr` and `sptr` are meant to be integer-typed containers for pointer addresses, and should be used in situations where pointer arithmetic is needed. `uptr/sptr` definitions are not type safe and `void*` or `u8*` should be used for parameter passing instead, when possible.
wxWidgets base types are no longer preferred, and should be avoided when possible, though they can be used as needed when dealing with gui code.
## Topic 3: Do not use `private` class members; use `protected` instead. ## Topic 3: Do not use `private` class members; use `protected` instead.
There is no justifiable reason for any class in PCSX2 to use private variable members. Private members are only useful in the context of _dynamically shared core libraries_, and only hinder the object extensibility of non-shared application code. Use `protected` for all non-public members instead, as it protects members from unwanted public access while still allowing the object to be extended into a derived class without having to waste a lot of silly effort to dance around private mess. There is no justifiable reason for any class in PCSX2 to use private variable members. Private members are only useful in the context of _dynamically shared core libraries_, and only hinder the object extensibility of non-shared application code. Use `protected` for all non-public members instead, as it protects members from unwanted public access while still allowing the object to be extended into a derived class without having to waste a lot of silly effort to dance around private mess.