Compare commits

...

2 Commits

Author SHA1 Message Date
sp2xdev 5bce47e487 Update CONTRIBUTING.md 2024-07-28 22:57:33 -07:00
sp2xdev ccf2009726 Update CONTRIBUTING.md 2024-07-27 18:50:20 -07:00
+3
View File
@@ -17,6 +17,8 @@ Additionally, there's a lot of code that get exercised on specific hardware - in
Therefore, when making code changes, please be extremely careful about containing / scoping your changes. Make targeted bug fixes scoped to handful of game versions and hardware configuration. When adding new features, make it off by default, unless there is a really good reason to make it the default. If you make a new default, add an option that disables it so that users can opt out as needed. Therefore, when making code changes, please be extremely careful about containing / scoping your changes. Make targeted bug fixes scoped to handful of game versions and hardware configuration. When adding new features, make it off by default, unless there is a really good reason to make it the default. If you make a new default, add an option that disables it so that users can opt out as needed.
Lastly, watch out for legacy OS compatibility. Currently, the minimum support floor is Windows 7. If you use any Windows API, make sure it's supported in Windows 7. If you need to use API that is not present in Windows 7, you must not directly link against it, otherwise spice will fail to launch on older OSes. Take a look at Windows 8 touch code (win8.cpp) for examples on how to discover OS APIs via pointers.
### Code quality requirements ### Code quality requirements
* Test for regressions, at least in and around the component you are modifying: * Test for regressions, at least in and around the component you are modifying:
@@ -29,3 +31,4 @@ Therefore, when making code changes, please be extremely careful about containin
* Do not make code changes in unrelated areas; i.e., do not run code linters and auto-formatters for parts of the code that you didn't modify. * Do not make code changes in unrelated areas; i.e., do not run code linters and auto-formatters for parts of the code that you didn't modify.
* Note: there are no strict rules for code formatting, but please attempt to emulate the style around the code you are modifying. * Note: there are no strict rules for code formatting, but please attempt to emulate the style around the code you are modifying.
* Try to submit smaller chunks of code, instead one gigantic patch. For example, don't submit a patch for "Improve feature XYZ"; instead, submit "Change how A works to prepare for feature XYZ" "Refactor B for feature XYZ" "Add feature B to enable feature XYZ". * Try to submit smaller chunks of code, instead one gigantic patch. For example, don't submit a patch for "Improve feature XYZ"; instead, submit "Change how A works to prepare for feature XYZ" "Refactor B for feature XYZ" "Add feature B to enable feature XYZ".
* Write to the log for anything useful - it helps immensely with debugging post-mortem. At the same time though, avoid spamming the log for something trivial.