C%2B%2B to C++

Code-Formatting-Guidelines.md

@@ -14,15 +14,15 @@ Besides being obscenely ugly, this naming convention is totally impractical for
 
 **Just don't do it. _Ever._**
 
-## Topic 2: Using PCSX2 and wxWidgets base types instead of C/C%2B%2B atomic types.
+## Topic 2: Using PCSX2 and wxWidgets 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%2B%2B atomic types. Most of the common types are:
+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:
 ```C++
 u8, s8, u16, s16, u32, s32, u64, s64, u128, s128, uptr, sptr
 ```
-These types ensure consistent operand sizes on all compilers and platforms, and should be used almost always when dealing with integer values. There are exceptions where the plain int type may be more ideal, however: typically C%2B%2B compilers define an `int` as a value at least 32 bits in length (upper range is compiler/platform specific), and temporary arithmetic operations often conform to this spec and thus can use `int` (a compiler may be allowed then to use whichever data type the target CPU is most efficient at handling). Other C%2B%2B integer types such as `short` and `long` should not be used for anything except explicit matching against externally defined 3rc party library functions. They are too unpredictable and have no upside over strict operand sizing.
+These types ensure consistent operand sizes on all compilers and platforms, and should be used almost always when dealing with integer values. There are exceptions where the plain int type may be more ideal, however: typically C++ compilers define an `int` as a value at least 32 bits in length (upper range is compiler/platform specific), and temporary arithmetic operations often conform to this spec and thus can use `int` (a compiler may be allowed then to use whichever data type the target CPU is most efficient at handling). Other C++ integer types such as `short` and `long` should not be used for anything except explicit matching against externally defined 3rc party library functions. They are too unpredictable and have no upside over strict operand sizing.
 
-Note that using the C%2B%2B atomic types `float` and `double` are acceptable, and that there are no defined alternatives at this time.
+Note that using the C++ atomic types `float` and `double` are acceptable, and that there are no defined alternatives at this time.
 
 **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.
 
@@ -46,7 +46,7 @@ void DoSomething() {
     Function1(); Function2();	var += 1;
 }
 ```
-The reason for this guideline is that it can assist debugging tremendously. Most C%2B%2B debuggers cannot breakpoint function calls to the bad example, disabling a programmer's ability to use the debugger to quickly track the calling patterns for a function or conditional, and thus removing one of the most ideal tools available to a programmer for understanding code execution patterns of code written by another programmer. For these reasons, code written with such compounding may likely be unrolled onto multiple lines by another programer at any time, if that programmer is tasked with troubleshooting bugs in that code.
+The reason for this guideline is that it can assist debugging tremendously. Most C++ debuggers cannot breakpoint function calls to the bad example, disabling a programmer's ability to use the debugger to quickly track the calling patterns for a function or conditional, and thus removing one of the most ideal tools available to a programmer for understanding code execution patterns of code written by another programmer. For these reasons, code written with such compounding may likely be unrolled onto multiple lines by another programer at any time, if that programmer is tasked with troubleshooting bugs in that code.
 
 If the operation of a function is simpler (one or two operations max), and if there are many such functions as part of a class or interface, then compounding on a single line for sake of compact readability may be justified; and in such cases the programmer should also use the inline_always attribute on the function to denote that it has a trivial and repetitive operation that can be ignored during debugging.