PCSX2 Documentation/Code Formatting Guidelines: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 37: Line 37:
==Topic 5: Avoid compounding complex operations onto a single line with a function declaration.==
==Topic 5: Avoid compounding complex operations onto a single line with a function declaration.==


**Example:**
===Example:===
// Not so good...
// Not so good...
  <code>void DoSomething() { Function1(); Function2(); var += 1; }</code>
  <code>void DoSomething() { Function1(); Function2(); var += 1; }</code>
Line 47: Line 47:
}
}
</code>
</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.
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.


Line 53: Line 54:
==Topic Ex: Specifying Function Inlining==
==Topic Ex: Specifying Function Inlining==


_**IMPORTANT**_ **This section is preliminary documentation for a planned design, and is not currently implemented in the PCSX2 sourcecode.**
'''''IMPORTANT''''' '''This section is preliminary documentation for a planned design, and is not currently implemented in the PCSX2 sourcecode.'''


While modern compilers like to tout that the compiler should be left to decide function inlining, the truth is that for PCSX2's purposes compiler inlining heuristics fail miserably, never inlining nearly as much as they should. It's often necessary for us as programmers to tell the compiler what to inline. PCSX2 offers four special classes of forced function inlining, which are provided as replacements for `__forceinline,` `inline,` and `__attribute__(always_inline)`. When used properly, these inlining attributes help improve the performance and quality of devel and debug builds.
While modern compilers like to tout that the compiler should be left to decide function inlining, the truth is that for PCSX2's purposes compiler inlining heuristics fail miserably, never inlining nearly as much as they should. It's often necessary for us as programmers to tell the compiler what to inline. PCSX2 offers four special classes of forced function inlining, which are provided as replacements for `__forceinline,` `inline,` and `__attribute__(always_inline)`. When used properly, these inlining attributes help improve the performance and quality of devel and debug builds.
ninja
782

edits