Code Review

Code review means checking code written by another developer or checking your own changes before they become part of the main project.

Developer Writes Code
        ↓
Code Review
        ↓
Feedback
        ↓
Improvements
        ↓
Merge

Code review provides an opportunity to inspect changes before they are integrated.

• Find potential bugs
• Improve code readability
• Share knowledge
• Check project conventions
• Discuss design decisions
• Improve maintainability
• Identify missing tests

GitHub Pull Requests provide a central place for reviewing proposed changes.

Feature Branch
      ↓
Pull Request
      ↓
Code Review
      ↓
Feedback
      ↓
Update Code
      ↓
Approval
      ↓
Merge

A reviewer is a person who examines the proposed changes in a pull request.

A reviewer may inspect:

• Changed files
• Code logic
• Tests
• Security concerns
• Performance
• Readability

A pull request can have one or more reviewers depending on the project's workflow.

Pull Request
      ↓
Reviewer 1
Reviewer 2
Reviewer 3
      ↓
Feedback

The repository's settings and team workflow determine how reviews are handled.

Reviewers should examine the files changed by the pull request.

Modified:
    login.php
    dashboard.php
    style.css

Reviewer checks each change.

Reviewing the actual diff helps identify exactly what changed.

A diff shows the differences between versions of a file.

+ Added line
- Removed line
  Unchanged context

The reviewer can use the diff to understand the changes without reading the entire project from the beginning.

Reviewers can check whether the code performs the intended task.

Input
  ↓
Validation
  ↓
Processing
  ↓
Output

The reviewer should consider whether the implementation handles normal and important edge cases correctly.

Readable code is easier for other developers to understand and maintain.

Reviewers may look at:

• Variable names
• Function names
• Code structure
• Indentation
• Comments
• Unnecessary complexity

Clear names make code easier to understand.

// Less descriptive
$x = 500;

// More descriptive
$totalFee = 500;

A reviewer can suggest clearer names when they improve understanding.

Reviewers can check whether functions have clear responsibilities.

function calculateTotalFee($fee, $fine)
{
    return $fee + $fine;
}

Small and focused functions can make code easier to understand and test.

Security should be considered during code review.

Reviewers may look for issues such as:

• Hard-coded passwords
• Exposed API keys
• Unsafe SQL queries
• Missing input validation
• Improper access control
• Sensitive information in commits

For applications using databases, reviewers should pay attention to how database queries are constructed.

// Prefer parameterized queries

$stmt = $pdo->prepare(
    "SELECT * FROM students WHERE id = ?"
);

$stmt->execute([$studentId]);

This approach helps avoid unsafe construction of SQL queries.

Reviewers can check whether important errors are handled properly.

try {
    // Database operation
} catch (Exception $e) {
    // Handle error
}

Good error handling can make applications easier to debug and more reliable.

A code review can include checking whether appropriate tests have been added or updated.

Code Change
    ↓
Run Tests
    ↓
Pass?
 ┌──┴──┐
Yes    No
 ↓      ↓
Review  Fix

Repositories can automatically run checks when a pull request is opened or updated.

• Unit tests
• Build processes
• Linters
• Type checks
• Security scans
• Other project-specific checks

Reviewers can leave comments to ask questions or suggest improvements.

Reviewer:
Could this function be simplified?

Developer:
Yes. I will refactor it.

Comments help developers discuss specific parts of the proposed changes.

A reviewer can suggest a specific modification when they see a better way to implement something.

Current:
return $a + $b + $c;

Suggestion:
return $total;

The exact review workflow depends on the repository and the changes being discussed.

When a change needs to be addressed before integration, a reviewer can request changes through the pull request review process.

Pull Request
     ↓
Review
     ↓
Changes Requested
     ↓
Developer Fixes Code
     ↓
New Commit
     ↓
Review Again

A reviewer can approve a pull request when the changes meet the project's review requirements.

Review
  ↓
Approved
  ↓
Required Checks
  ↓
Merge

Approval requirements can vary between repositories.

If changes are requested, the developer can modify the code locally, commit the changes, and push them to the same source branch.

git add .
git commit -m "Address review comments"
git push

The existing pull request can then reflect the new commit.

Developers should review their own changes before asking others to review the pull request.

• Read the changed code.
• Check the diff.
• Remove debugging code.
• Check formatting.
• Run tests.
• Verify the pull request description.

A focused pull request is generally easier to review than a pull request containing many unrelated changes.

Good:
Add login validation

Avoid:
Login + payment + redesign +
database migration + unrelated fixes

Keeping related work together can make discussion clearer.

Code review should focus on the code and the project requirements, not on attacking the person who wrote the code.

Prefer constructive comments such as:

"Could we simplify this function
to make it easier to maintain?"

Clear and respectful communication helps teams collaborate effectively.

• Reviewing without understanding the purpose of the change.
• Ignoring security issues.
• Ignoring test results.
• Making unrelated comments.
• Not explaining important feedback.
• Reviewing too many unrelated changes at once.
• Ignoring project coding standards.
• Approving changes without checking important files.

• Understand the purpose of the pull request.
• Check the changed files.
• Read the important code changes.
• Check logic.
• Check error handling.
• Check security.
• Check tests.
• Check readability.
• Check project conventions.
• Review automated checks.

Pull Request:
Add student registration

Reviewer checks:

1. Form validation
2. Database query
3. Duplicate student handling
4. Password handling
5. Error messages
6. Tests
7. Code readability

Result:
Changes requested

Developer fixes the issues
and pushes a new commit.

Developer
    ↓
Create Feature Branch
    ↓
Write Code
    ↓
Commit Changes
    ↓
Push Branch
    ↓
Create Pull Request
    ↓
Self Review
    ↓
Reviewer
    ↓
Comments / Suggestions
    ↓
Developer Updates Code
    ↓
Automated Checks
    ↓
Approval
    ↓
Merge

• Keep pull requests reasonably focused.
• Explain the purpose of the change.
• Review the diff carefully.
• Use clear and constructive comments.
• Check tests and automated checks.
• Look for security problems.
• Follow project conventions.
• Ask questions when the code is unclear.
• Resolve important review discussions before merging.
• Keep the review focused on the proposed change.

Code review is an important part of collaborative software development. GitHub Pull Requests provide a convenient place for developers to inspect changes, discuss code, run checks, request updates, and approve proposed changes.

Write Code
    ↓
Create Pull Request
    ↓
Review Changes
    ↓
Discuss
    ↓
Fix Problems
    ↓
Run Tests
    ↓
Approve
    ↓
Merge

A good code review focuses on correctness, security, readability, maintainability, testing, and the requirements of the project.