Default resources - Contributing: Difference between revisions
Fernando187 (talk | contribs) mNo edit summary |
Fernando187 (talk | contribs) mNo edit summary |
||
Line 26: | Line 26: | ||
<p>To improve code readability, prefer using early returns to handle error conditions or special cases at the beginning of functions. This helps to avoid deep nesting and makes the main logic easier to follow.</p> | <p>To improve code readability, prefer using early returns to handle error conditions or special cases at the beginning of functions. This helps to avoid deep nesting and makes the main logic easier to follow.</p> | ||
<pre> | <pre> | ||
< | <syntaxhighlight lang="lua"> | ||
-- Bad example | -- Bad example | ||
function exampleFunction(value) | function exampleFunction(value) | ||
Line 48: | Line 48: | ||
-- Main logic here | -- Main logic here | ||
end | end | ||
</ | </syntaxhighlight> | ||
</pre> | </pre> | ||
<h3>Script Security</h3> | <h3>Script Security</h3> | ||
<p>Follow the [[Script security]] principles.</p> | <p>Follow the [[Script security]] principles established for MTA:SA scripts.</p> | ||
<h3>Performance Considerations</h3> | <h3>Performance Considerations</h3> |
Revision as of 11:34, 29 June 2024
This article contains the official set of rules and guidelines for contributing to the Default resources that come with MTA.
WORK IN PROGRESS
Contributing to mtasa-resources
Welcome to the mtasa-resources project! We appreciate your interest in contributing to the development and improvement of the default Lua resources that come with the MTA:SA multiplayer mod. To ensure high-quality code and a smooth collaboration process, please adhere to the following coding guidelines and contributing rules.
Coding Guidelines
General Principles
- Write clear, readable, and maintainable code.
- Follow the DRY (Don't Repeat Yourself) principle.
- Adhere to the KISS (Keep It Simple, Stupid) principle.
- Use meaningful variable and function names that convey the purpose.
- Comment your code where necessary to explain the logic.
Indentation and Formatting
Make sure your code editor is applying the rules established in the project's root .editorconfig file.
Early Return
To improve code readability, prefer using early returns to handle error conditions or special cases at the beginning of functions. This helps to avoid deep nesting and makes the main logic easier to follow.
<syntaxhighlight lang="lua"> -- Bad example function exampleFunction(value) if value > 0 then -- Some logic here if value < 100 then -- More logic here if value ~= 50 then -- Main logic here end end end end -- Good example function exampleFunction(value) if value <= 0 then return end if value >= 100 then return end if value == 50 then return end -- Main logic here end </syntaxhighlight>
Script Security
Follow the Script security principles established for MTA:SA scripts.
Performance Considerations
- Avoid unnecessary computations within loops.
- Cache results of expensive operations when possible.
- Use local variables to improve performance.
Contributing Rules
Submitting Issues
- Check the existing issues before submitting a new one to avoid duplicates.
- Provide a clear and descriptive title and detailed information about the issue.
- Include steps to reproduce the issue, if applicable.
Submitting Pull Requests
- Fork the repository and create a new branch for your feature or bugfix.
- Ensure your code follows the coding guidelines outlined above.
- Include a clear and descriptive title and description of your changes.
- Reference any related issues in your pull request description.
- Ensure your code does not introduce new issues or break existing functionality.
- Be responsive to feedback and make necessary changes requested during the review process.
Review Process
- All pull requests will be reviewed by project maintainers.
- Feedback and requests for changes will be provided through the pull request comments.
- Once approved, your pull request will be merged into the main branch.