Definition

Code review is the systematic examination of source code by one or more developers other than the original author, with the goal of identifying defects, enforcing quality standards, improving design, and transferring knowledge across a team. In modern software engineering, code reviews operate at the intersection of automated tooling and human judgment -- static analyzers catch deterministic violations while human reviewers evaluate design decisions, architectural fitness, and domain correctness. In the Prismatic Platform, code reviews represent a multi-layered quality enforcement mechanism where automated analysis through Credo and Dialyzer forms the first line of defense, backed by NO MERCY, NO DOUBTS doctrine enforcement that tolerates zero quality violations.

Overview

The practice of code review has evolved from informal desk checks in the 1970s to structured inspection processes pioneered by Michael Fagan at IBM, and finally to the modern lightweight review model enabled by version control platforms like GitHub, GitLab, and Bitbucket. Research consistently demonstrates that code review is one of the most effective quality assurance techniques available -- studies at Microsoft, Google, and SmartBear have shown that reviews catch between 60-90% of defects before they reach production, significantly outperforming testing alone.

Code reviews serve multiple purposes simultaneously. The primary purpose is defect detection: finding bugs, logic errors, edge cases, and security vulnerabilities before code reaches production. The secondary purpose is quality enforcement: ensuring code adheres to established standards, patterns, and architectural guidelines. The tertiary purpose is knowledge transfer: reviews spread understanding of the codebase across the team, reducing bus factor risk and building collective ownership. A well-executed code review process also serves as a mentoring mechanism, where senior developers provide feedback that helps junior developers grow their skills and understanding.

In the Elixir ecosystem, code reviews gain additional dimensions because of the language's functional nature and OTP patterns. Reviewers evaluate not just correctness but also whether the code properly leverages BEAM VM capabilities -- whether state is correctly isolated in processes, whether supervision trees are properly structured, whether functions are pure where they should be, and whether the code could have been written identically in a non-functional language (which, per Prismatic's meta-rule, means it is wrong).

Technical Details

Anatomy of an Effective Code Review

A comprehensive code review evaluates multiple dimensions of code quality:

Dimension	Focus Areas	Automated	Human
Correctness	Logic errors, edge cases, off-by-one	Partial (tests)	Primary
Security	Input validation, injection, auth	Static analysis	Primary
Performance	N+1 queries, memory leaks, complexity	Benchmarks	Secondary
Design	Patterns, coupling, cohesion, SRP	Limited	Primary
Readability	Naming, comments, documentation	Linters	Primary
OTP Compliance	Supervision, process isolation, purity	Custom checks	Primary
Type Safety	Specs, dialyzer compliance, contracts	Dialyzer	Secondary
Test Quality	Coverage, edge cases, regression tests	Coverage tools	Primary

Review Process Stages

The modern code review process follows a structured workflow:

Pre-Review Automation: Before any human reviews the code, automated tools run static analysis, compilation checks, and test suites. In Prismatic, this means mix compile --warnings-as-errors, mix credo --strict, mix dialyzer, and mix test --cover must all pass.
Initial Review: The reviewer reads the change description, understands the intent, and performs a high-level scan of the diff to assess scope and approach.
Detailed Analysis: Line-by-line examination of the code, checking each dimension in the table above. The reviewer annotates specific lines with comments, questions, and suggestions.
Design Discussion: For significant changes, the reviewer evaluates architectural decisions, pattern usage, and long-term maintainability.
Resolution: The author addresses each comment -- either making requested changes or providing justification for the current approach.
Final Verification: The reviewer confirms all concerns have been addressed and approves the change.

Automated Review Tooling in Elixir

defmodule Prismatic.Quality.CodeReviewPipeline do
  @moduledoc """
  Orchestrates the automated portion of code review by running
  multiple analysis tools in sequence and aggregating results.

  The pipeline enforces NO MERCY doctrine: any single failure
  blocks the entire review from proceeding to human review.
  """

  @type review_result :: %{
          tool: atom(),
          status: :pass | :fail,
          violations: list(violation()),
          duration_ms: non_neg_integer()
        }

  @type violation :: %{
          file: String.t(),
          line: pos_integer(),
          message: String.t(),
          severity: :warning | :error | :critical
        }

  @type pipeline_result :: {:ok, list(review_result())} | {:error, list(review_result())}

  @spec run_pipeline(list(String.t())) :: pipeline_result()
  def run_pipeline(changed_files) when is_list(changed_files) do
    results =
      [
        &check_compilation/1,
        &check_credo/1,
        &check_dialyzer/1,
        &check_test_coverage/1,
        &check_forbidden_patterns/1,
        &check_typespec_coverage/1
      ]
      |> Enum.map(fn check -> check.(changed_files) end)

    case Enum.any?(results, fn r -> r.status == :fail end) do
      true -> {:error, results}
      false -> {:ok, results}
    end
  end

  @spec check_compilation(list(String.t())) :: review_result()
  defp check_compilation(files) do
    {_output, exit_code} =
      System.cmd("mix", ["compile", "--warnings-as-errors", "--force"],
        stderr_to_stdout: true
      )

    %{
      tool: :compilation,
      status: if(exit_code == 0, do: :pass, else: :fail),
      violations: parse_compilation_warnings(files),
      duration_ms: 0
    }
  end

  @spec check_credo(list(String.t())) :: review_result()
  defp check_credo(files) do
    args = ["credo", "--strict", "--format", "json" | Enum.flat_map(files, &["--files-included", &1])]
    {output, exit_code} = System.cmd("mix", args, stderr_to_stdout: true)

    %{
      tool: :credo,
      status: if(exit_code == 0, do: :pass, else: :fail),
      violations: parse_credo_output(output, files),
      duration_ms: 0
    }
  end

  @spec check_dialyzer(list(String.t())) :: review_result()
  defp check_dialyzer(_files) do
    {output, exit_code} = System.cmd("mix", ["dialyzer"], stderr_to_stdout: true)

    %{
      tool: :dialyzer,
      status: if(exit_code == 0, do: :pass, else: :fail),
      violations: parse_dialyzer_output(output),
      duration_ms: 0
    }
  end

  @spec check_test_coverage(list(String.t())) :: review_result()
  defp check_test_coverage(_files) do
    {output, exit_code} = System.cmd("mix", ["test", "--cover"], stderr_to_stdout: true)

    %{
      tool: :test_coverage,
      status: if(exit_code == 0, do: :pass, else: :fail),
      violations: parse_coverage_output(output),
      duration_ms: 0
    }
  end

  @spec check_forbidden_patterns(list(String.t())) :: review_result()
  defp check_forbidden_patterns(files) do
    violations = Enum.flat_map(files, &scan_forbidden_patterns/1)

    %{
      tool: :forbidden_patterns,
      status: if(violations == [], do: :pass, else: :fail),
      violations: violations,
      duration_ms: 0
    }
  end

  @spec check_typespec_coverage(list(String.t())) :: review_result()
  defp check_typespec_coverage(files) do
    violations = Enum.flat_map(files, &check_specs/1)

    %{
      tool: :typespec_coverage,
      status: if(violations == [], do: :pass, else: :fail),
      violations: violations,
      duration_ms: 0
    }
  end

  defp parse_compilation_warnings(_files), do: []
  defp parse_credo_output(_output, _files), do: []
  defp parse_dialyzer_output(_output), do: []
  defp parse_coverage_output(_output), do: []
  defp scan_forbidden_patterns(_file), do: []
  defp check_specs(_file), do: []
end

Pre-Commit Hook Integration

Prismatic enforces automated code review at the git hook level through an 11-phase pre-commit system:

#!/usr/bin/env bash
# Prismatic Pre-Commit Review Pipeline (simplified)
# Phase 1: Compilation (--warnings-as-errors)
# Phase 2: Credo strict analysis
# Phase 3: Dialyzer type checking
# Phase 4: Test execution with coverage
# Phase 5: Forbidden pattern detection
# Phase 6: Typespec coverage verification
# Phase 7: Quality gate checks
# Phase 8: Template validation
# Phase 9: Performance benchmarks
# Phase 10: Design consistency
# Phase 11: Final quality score computation

mix compile --warnings-as-errors --force || exit 1
mix credo --strict || exit 1
mix quality.forbidden_patterns || exit 1
mix test --cover || exit 1

Review Metrics and Feedback Loops

Metric	Target	Measurement
Review turnaround time	< 24 hours	Time from MR creation to first review
Defect detection rate	> 70%	Bugs found in review vs. found in production
Review coverage	100%	All changes reviewed before merge
Automated gate pass rate	> 95%	MRs passing all automated checks on first submission
Knowledge distribution	> 3 reviewers per module	Number of developers who have reviewed code in each module

Implementation in Prismatic Platform

Multi-Layer Review Architecture

The Prismatic Platform implements code reviews through a layered architecture that combines automated tooling with doctrine enforcement:

Layer 1 -- Automated Static Analysis: Every code change passes through Credo (style and consistency), Dialyzer (type correctness), and custom quality checks. Zero violations are permitted under the Zero Warning Policy.

Layer 2 -- Forbidden Pattern Detection: Automated scanning blocks mocks, stubs, placeholders, hardcoded values, and naive implementations. The mix quality.forbidden_patterns task enforces this with categories for mocks, stubs, placeholders, naive code, and localhost references.

Layer 3 -- Quality Gate Enforcement: The mix quality.gates command runs comprehensive static analysis that must pass before any merge. This includes compilation warnings, Credo violations, Dialyzer errors, typespec coverage, and forbidden pattern detection.

Layer 4 -- Pre-Commit Hooks: An 11-phase pre-commit hook pipeline runs automatically on every commit attempt, blocking commits that violate any quality standard.

Layer 5 -- Doctrine Enforcement: The NO MERCY, NO DOUBTS doctrine governs all review decisions. There are no partial passes -- code either meets every standard or it does not merge. This removes subjective judgment from quality decisions and ensures consistent enforcement.

Quality DNA Integration

Review outcomes feed into the Quality DNA system, which tracks quality metrics across sessions. Each review contributes to the platform's quality score (currently 100/100 across 13 domains), and any regression triggers automatic investigation and correction.

AIAD Agent Support

Several AIAD agents assist with code review:

elixir-architect: Evaluates OTP compliance, supervision tree design, and functional purity
quality-floor-guardian: Monitors quality metrics and blocks regressions
autoevolve agents: Automatically suggest improvements based on detected patterns

Comparison with Alternatives

Approach	Defect Detection	Knowledge Transfer	Speed	Scalability
Peer Code Review	High (60-90%)	Excellent	Moderate	Moderate
Pair Programming	High (70-85%)	Excellent	Slow	Poor
Automated Analysis Only	Moderate (30-50%)	None	Fast	Excellent
Formal Inspection (Fagan)	Very High (80-95%)	Good	Very Slow	Poor
Prismatic Multi-Layer	Very High (90%+)	Good	Fast (automated)	Excellent
AI-Assisted Review	Moderate-High	Limited	Fast	Excellent

The Prismatic approach combines the high defect detection rate of formal inspections with the speed and scalability of automated analysis. By making the automated layer comprehensive enough to catch the majority of issues, human reviewers can focus on higher-level concerns like design quality and architectural fitness.

Best Practices

Review small changes frequently: Large diffs are harder to review thoroughly. Keep merge requests focused on a single concern.
Automate everything automatable: Use static analysis tools to catch style, type, and pattern violations automatically, freeing human reviewers for higher-order concerns.
Review the design, not just the code: Evaluate whether the approach is sound, not just whether the implementation is correct.
Provide actionable feedback: Every review comment should either identify a specific issue or suggest a specific improvement. Avoid vague criticism.
Enforce consistency through tooling: Use linters, formatters, and custom checks to eliminate subjective style debates from reviews.
Require regression tests for bug fixes: Every bug fix must include a test that would have caught the bug, verified to fail before the fix and pass after.
Track review metrics: Measure turnaround time, defect detection rate, and coverage to identify process improvements.
Rotate reviewers: Ensure multiple team members review each area of the codebase to distribute knowledge and reduce bus factor.

Common Pitfalls

Rubber-stamping: Approving changes without thorough examination, often due to time pressure or reviewer fatigue. Countered in Prismatic by automated gates that catch issues regardless of reviewer diligence.
Bikeshedding: Spending disproportionate time on trivial style issues while overlooking substantive design problems. Automated formatters and linters eliminate style debates entirely.
Toxic review culture: Reviews that are hostile, dismissive, or personal rather than constructive and focused on the code. The NO MERCY doctrine applies to code quality, not to interpersonal interactions.
Ignoring automated results: Treating static analysis warnings as noise rather than genuine issues. The zero-warning policy eliminates this by making all warnings blocking errors.
Review scope creep: Requesting unrelated changes during review that expand scope beyond the original intent. Reviews should focus on the change at hand.
Single reviewer dependency: Relying on one person to review all changes creates a bottleneck and concentrates knowledge. Rotating reviewers prevents this.
Skipping reviews for "small" changes: Even one-line changes can introduce critical bugs. All changes go through the full review pipeline.
Not reviewing tests: Tests are code too and deserve the same review attention as production code. Poorly written tests provide false confidence.

Use Cases

Continuous Integration Pipeline

Every merge request triggers the automated review pipeline. The CI system runs all quality checks, and only changes that pass every gate proceed to human review. This ensures that reviewers never waste time on code that has basic quality issues.

Onboarding New Developers

Code reviews serve as an accelerated learning mechanism for new team members. By reviewing code across different areas of the platform, new developers quickly build understanding of patterns, conventions, and architectural decisions. The review comments themselves form a knowledge base of "why" decisions.

Security-Critical Changes

Changes to authentication, authorization, data handling, or security-sensitive modules receive additional scrutiny. In Prismatic, these changes also trigger Color Team evaluation where Red Team agents probe the change for potential vulnerabilities.

Architectural Evolution

When refactoring or introducing new architectural patterns, code reviews ensure that changes are consistent with the platform's design principles and that new patterns are properly documented and tested.

Regression Prevention

Every bug fix goes through a review that specifically verifies the inclusion of regression tests. The mandatory regression test protocol requires that tests fail before the fix and pass after, providing confidence that the specific bug cannot recur.

Code Quality -- The broader discipline of maintaining high-quality source code
Credo -- Elixir static analysis tool for style and consistency checking
Dialyzer -- Erlang/Elixir type analysis tool for detecting type errors
Static Analysis -- Automated examination of code without execution
Quality Gate -- Checkpoints that code must pass before proceeding
Zero Warning Policy -- Enforcement of zero compilation warnings
Quality DNA -- Cross-session quality tracking and continuity system
Clean Run -- Requirement for no runtime warnings or debug logs
Collaborative Development -- Team-based software development practices
Quality Gates -- Automated quality enforcement checkpoints

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

Code Reviews

Definition

Overview

Technical Details

Anatomy of an Effective Code Review

Review Process Stages

Automated Review Tooling in Elixir

Pre-Commit Hook Integration

Review Metrics and Feedback Loops

Implementation in Prismatic Platform

Multi-Layer Review Architecture

Quality DNA Integration

AIAD Agent Support

Comparison with Alternatives

Best Practices

Common Pitfalls

Use Cases

Continuous Integration Pipeline

Onboarding New Developers

Security-Critical Changes

Architectural Evolution

Regression Prevention

See Also

Connect & Contribute

Glossary

Related Terms

Code Reviews

Definition

Overview

Technical Details

Anatomy of an Effective Code Review

Review Process Stages

Automated Review Tooling in Elixir

Pre-Commit Hook Integration

Review Metrics and Feedback Loops

Implementation in Prismatic Platform

Multi-Layer Review Architecture

Quality DNA Integration

AIAD Agent Support

Comparison with Alternatives

Best Practices

Common Pitfalls

Use Cases

Continuous Integration Pipeline

Onboarding New Developers

Security-Critical Changes

Architectural Evolution

Regression Prevention

Related Concepts

See Also

Connect & Contribute

Glossary

Related Terms