PCSX2 Documentation/Code Formatting Guidelines: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 15: Line 15:
'''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 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++ 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:
Line 27: Line 27:
**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.


## 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.


## Topic 4: Name Protected Class Members with `'m_'`
==Topic 4: Name Protected Class Members with 'm_'==


It is highly recommended to prefix protected class members with `m_`; such as `m_SomeVar` or `m_somevar`. This is a widely accepted convention that many IDEs are adding special built in support and handling for, and for that reason it can help improve class organization considerably for all contributors to the project. However, like most other guidelines it is not a definitive requirement.
It is highly recommended to prefix protected class members with `m_`; such as `m_SomeVar` or `m_somevar`. This is a widely accepted convention that many IDEs are adding special built in support and handling for, and for that reason it can help improve class organization considerably for all contributors to the project. However, like most other guidelines it is not a definitive requirement.


## 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:**
Line 51: Line 51:
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.
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.


## 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.**
Line 65: Line 65:
**`inline_never`** special attribute which force-disables inlining of a function completely. This attribute is of extremely limited use, usually to combat stupid inlining tricks that some compilers might fall into on special cases of complex function nesting, so you probably won't even need to remember it exists unless you make a habit of writing complex and hard to understand class implementations.
**`inline_never`** special attribute which force-disables inlining of a function completely. This attribute is of extremely limited use, usually to combat stupid inlining tricks that some compilers might fall into on special cases of complex function nesting, so you probably won't even need to remember it exists unless you make a habit of writing complex and hard to understand class implementations.


### Topic Ex.2: Savestate Versioning
===Topic Ex.2: Savestate Versioning===


While PCSX2 willfully makes no promise to retain backwards support for savestates, it is none the less a convenience for developer, tester, and user alike when we do. So when possible it is recommended that programmers making changes to the savestate code (normally denoted as a Freeze() function) be sure to increment the savestate version in Savestate.h and, if you know how, implement backward support for the old version (if not, then simply increment the savestate version and let someone else fix the backwards compatibility in a later revision). This allows PCSX2 to at the very least fail gracefully when encountering an unknown savestate, and ideally it allows for another coder familiar with the system to properly implement backwards compatibility with the older savestate revision.
While PCSX2 willfully makes no promise to retain backwards support for savestates, it is none the less a convenience for developer, tester, and user alike when we do. So when possible it is recommended that programmers making changes to the savestate code (normally denoted as a Freeze() function) be sure to increment the savestate version in Savestate.h and, if you know how, implement backward support for the old version (if not, then simply increment the savestate version and let someone else fix the backwards compatibility in a later revision). This allows PCSX2 to at the very least fail gracefully when encountering an unknown savestate, and ideally it allows for another coder familiar with the system to properly implement backwards compatibility with the older savestate revision.


   [1]: http://en.wikipedia.org/wiki/Hungarian_notation
   [1]: http://en.wikipedia.org/wiki/Hungarian_notation
ninja
782

edits

Navigation menu