Coding style

We recommend to follow these guidelines when writing code for Vita3K. They aren't very strict rules since we want to be flexible and we understand that under certain circumstances some of them can be counterproductive. Just try to follow as many of them as possible:

Casing

• function_name
• variable_name
• CONSTANT_NAME
• TypeName
• MACRO_NAME

Special exception: HLE function names, arguments and types should match those from the vitasdk headers. Cmd-clicking on an EXPORT name in Xcode should take you to the declaration in the vitasdk headers so it's easy to copy and paste the return type and arguments. Variables inside the function should follow the standard style though.

Formatting

Use the provided .clang-format rules. You don't have to do this all the time, and there's no point being precious about it, but expect someone to run clang-format sometimes.

General coding style

• Avoid #defines, use constant variables instead.
• Minimise code in header files. If you can forward declare rather than #include, please do so. If you can declare in a header and implement in a .cpp file, please do that too.
• Avoid inline functions until they become a demonstrated performance problem.
• Try to eliminate all compiler warnings from your code.
• Try to use C++ standard data types whenever it's possible (e.g. std::string instead of wxString).
• Don't add unnecessary comments.
• Comment every hack you do and every improvable code.
• If you have to comment, include the reasons to do that in the comment.
• Don't comment out code -- just delete it.
• Ensure that the every source file you modify has the newline at the end of file. Every line ends with "newline" and the end of file must have "newline" too, GitHub usually warns about it.
• Use standard types from <cstdint> when you need sized types such as std::uint32_t.

Git history

Commit messages

Git commit messages should be of the form:

module: Summary text

Optional description.

Where module is something like gxm (or kernel/io if it contains changes in multiple areas, or if the author wishes to specify the changes further, ie. kernel/sync).

The summary should not end in a period. The description can be omitted if the summary explains the change enough.

Pull request merging

• Pull request merges should generally be done using a Rebase or a Merge commit rather than a Squash, unless the history is particularly messy (i.e. includes experiments or back and fore changes) and a Squash would improve it.

• If the PR in question contains unrelated commits, prefer Rebasing to a Merge commit.

• If the PR author has push-access, it is advised for everyone else to only review and not merge it, giving the change for further changes and selection of merge method to the original author.