docs: update README.md

readablity -> readability
This commit is contained in:
Ikko Eltociear Ashimine 2024-07-28 00:44:34 +09:00 committed by GitHub
parent a7a5dfa24e
commit a677a58c2c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -69,7 +69,7 @@ The core idea of stocknear shall always be: ***Fast*** & ***Simple***.
If want to contribute to the codebase please follow these guidelines: If want to contribute to the codebase please follow these guidelines:
- Refactoring slow code into fast code is a huge plus! - Refactoring slow code into fast code is a huge plus!
- Reducing complexity and increasing simplicity/readability is a huge plus! - Reducing complexity and increasing simplicity/readability is a huge plus!
- Anything you claim is a "speedup" must be benchmarked. In general, the goal is simplicity, so even if your PR makes things marginally faster, you have to consider the tradeoff with maintainablity and readablity. - Anything you claim is a "speedup" must be benchmarked. In general, the goal is simplicity, so even if your PR makes things marginally faster, you have to consider the tradeoff with maintainablity and readability.
- If your PR looks "complex", is a big diff, or adds lots of lines, it won't be reviewed or merged. Consider breaking it up into smaller PRs that are individually clear wins. A common pattern I see is prerequisite refactors before adding new functionality. If you can (cleanly) refactor to the point that the feature is a 3 line change, this is great, and something easy for us to review. - If your PR looks "complex", is a big diff, or adds lots of lines, it won't be reviewed or merged. Consider breaking it up into smaller PRs that are individually clear wins. A common pattern I see is prerequisite refactors before adding new functionality. If you can (cleanly) refactor to the point that the feature is a 3 line change, this is great, and something easy for us to review.
# Support ❤️ # Support ❤️