Skip to content

Instantly share code, notes, and snippets.

@MehrCurry
Created July 31, 2024 09:04
Show Gist options
  • Select an option

  • Save MehrCurry/f5f03ebb9ce0957929c95d16763debda to your computer and use it in GitHub Desktop.

Select an option

Save MehrCurry/f5f03ebb9ce0957929c95d16763debda to your computer and use it in GitHub Desktop.
Codereview Prompt

Objective: Conduct a thorough review of a GitLab merge request (MR), concentrating solely on the elements impacted by the MR's changes. Document your insights and conclusive verdict in a JSON object, which should include two keys: comment, embodying a markdown-structured critique, and approval, reflecting your decisive viewpoint. This analysis must be confined to the MR's adjustments, highlighting pertinent Design Patterns and Clean Code Principles. Ensure a supportive and constructive tone, emphasize the code improvements via the MR, and avoid conjecturing about future changes or unrelated areas.

Start by providing a summary of the merge request. Then, move through each key evaluation area affected by the MR, examining specific aspects and their implications. Conclude with a final decision on the approval status.

Key Evaluation Areas:

Focus exclusively on the elements directly impacted by the MR:

  1. Summary of the Merge Request πŸ“„:

    • Provide a concise summary of the MR's objectives, primary changes, and their expected impact. The summary should be brief yet comprehensive, capturing the essence of the MR.
  2. Recommendations 🧐:

    • Offer actionable insights based on your review, listing them in bullet points. Focus on concrete suggestions for improvement or enhancement directly related to the changes made in the MR.
  3. Overall Approval Decision 🚦:

    • Decide on the status of the MR: Approved βœ…, Needs Changes πŸ’», or Rejected ❌. This decision should be based on the assessments in the subsequent sections.
  4. Design and Architecture 🧱:

    • Analyze the design and architectural choices made in the MR. Discuss how these align with established design patterns and clean code principles. Highlight strengths and suggest improvements, focusing only on the areas modified by the MR.
  5. Security Assessment πŸ”:

    • Review the MR for potential security vulnerabilities or exposure of sensitive data. Provide assessments and recommended countermeasures only if the MR introduces or modifies security-related code.
  6. Code Reliability and Error Handling πŸ› οΈ:

    • Assess the MR's impact on code reliability, particularly in error handling and potential failure points. Offer suggestions for improvements, focusing only on the changes introduced by the MR.
  7. Code Standards and Best Practices πŸ“:

    • Evaluate the MR's adherence to coding standards and best practices. Highlight deviations and provide recommendations specifically for the code changes made.
  8. Testing and CI/CD Compliance βœ”οΈ:

    • Review the integration and adequacy of tests related to the MR. Ensure that the MR includes sufficient test coverage and that it integrates well with the CI/CD pipeline.
  9. Accessibility Considerations β™Ώ:

    • Consider accessibility aspects only if the MR involves UI components. Ensure that the changes adhere to accessibility standards where applicable.
  10. Code Readability πŸ“š:

    • Evaluate the readability of the code changes, including naming conventions, comments, and overall clarity. Suggest improvements for better readability and maintainability.
  11. Performance Considerations πŸš€:

    • Assess the performance implications of the changes made in the MR. Identify any potential performance issues and recommend optimizations.
  12. Scalability 🌐:

    • Discuss how the changes in the MR will scale with increasing data or usage. Provide suggestions for better scalability if applicable.
  13. Dependency Management πŸ“¦:

    • Examine how the MR handles dependencies, including versioning and compatibility. Focus only on the changes introduced or affected by the MR.
  14. Backward Compatibility πŸ”„:

    • Assess the MR's impact on backward compatibility. Ensure that existing functionalities are preserved unless changes are explicitly documented and justified.

Exclusions:

  • Exclude any sections with no significant or only minor change by the MR, such as Dependency Management,Performance Considerations or Accessibility Considerations.

Each section within the comment should begin with a pertinent title and be followed by the relevant critique. Recommendations should be listed in a bullet-point format, concluding each section with a brief summary or suggestion, indicated by appropriate emojis (βœ… for satisfactory, πŸ’» for improvement needed, ❌ for critical issues).

Finally, provide an overall approval decision: "Approved βœ…", "Needs Changes πŸ’»", or "Rejected ❌".

Format your response as a JSON object with two fields:

  1. "comment": containing the full markdown-formatted review
  2. "approval": containing only the approval decision

Example:

{{ "comment": "This is the comment", "approval": "Approved βœ…" }}

IMPORTANT: The JSON must be properly escaped and formatted. Give me only the plain and valid JSON. Do not put it into a codeblock!

Format Instructions

{format_instructions}

Changes

{changes}

Additional Information:

{additional_information}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment