Merge pull request #1 from deathkel/add-code-review

Add code review guidelines and process

Author: deathkel

CODE_REVIEW.md

@@ -0,0 +1,41 @@
+# Code Review Guidelines
+
+## Code Review Process
+
+1. **Create a Pull Request**: When you have completed a feature or bug fix, create a pull request (PR) to the main branch.
+2. **Assign Reviewers**: Assign at least one reviewer to your PR. Preferably, choose someone who is familiar with the codebase.
+3. **Review the Code**: The assigned reviewer(s) will review the code, checking for functionality, readability, and adherence to coding standards.
+4. **Address Feedback**: If the reviewer(s) request changes, address the feedback and update the PR.
+5. **Approval and Merge**: Once the reviewer(s) approve the PR, it can be merged into the main branch.
+
+## Best Practices
+
+- **Write Clear and Concise Code**: Ensure your code is easy to read and understand.
+- **Follow Coding Standards**: Adhere to the project's coding standards and guidelines.
+- **Test Your Code**: Write unit tests for your code and ensure all tests pass before submitting a PR.
+- **Keep PRs Small**: Submit small, focused PRs that are easier to review.
+- **Provide Context**: Include a clear description of the changes in your PR and any relevant context.
+
+## Common Issues
+
+- **Lack of Tests**: Ensure your code is well-tested.
+- **Poor Naming Conventions**: Use meaningful and descriptive names for variables, functions, and classes.
+- **Inconsistent Formatting**: Follow the project's formatting guidelines.
+- **Large PRs**: Break down large PRs into smaller, more manageable ones.
+- **Lack of Documentation**: Document your code and provide comments where necessary.
+
+## Examples of Good and Bad Code Reviews
+
+### Good Code Review
+
+- **Positive Feedback**: "Great job on this feature! The code is clean and well-organized."
+- **Constructive Criticism**: "I noticed a potential issue with the error handling. Could you add a check for null values?"
+- **Suggestions for Improvement**: "Consider using a more descriptive variable name here to improve readability."
+
+### Bad Code Review
+
+- **Negative Feedback**: "This code is terrible. You need to rewrite it."
+- **Unclear Comments**: "Fix this."
+- **Lack of Specificity**: "This needs improvement."
+
+By following these guidelines, we can ensure a smooth and effective code review process that helps maintain the quality of our codebase.

CONTRIBUTING.md

@@ -47,3 +47,15 @@ Before submitting a pull request:
 - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
 
 **Happy coding**!
+
+## Code Review Guidelines
+
+When submitting a pull request, please follow these code review guidelines:
+
+1. **Create a Pull Request**: When you have completed a feature or bug fix, create a pull request (PR) to the main branch.
+2. **Assign Reviewers**: Assign at least one reviewer to your PR. Preferably, choose someone who is familiar with the codebase.
+3. **Review the Code**: The assigned reviewer(s) will review the code, checking for functionality, readability, and adherence to coding standards.
+4. **Address Feedback**: If the reviewer(s) request changes, address the feedback and update the PR.
+5. **Approval and Merge**: Once the reviewer(s) approve the PR, it can be merged into the main branch.
+
+By following these guidelines, we can ensure a smooth and effective code review process that helps maintain the quality of our codebase.

README.md

@@ -46,6 +46,9 @@ $app->configure('apidoc');
 ## Documentation
 Check out the documentation at the [Beyond Code homepage](https://beyondco.de/docs/laravel-apidoc-generator/).
 
+## Code Review Process
+We have a code review process in place to ensure the quality and consistency of our codebase. Please refer to the [Code Review Guidelines](CODE_REVIEW.md) for more information.
+
 ### License
 
 The Laravel API Documentation Generator is free software licensed under the MIT license.