Awesome Code Review RSS Feed

Datadog Code Security for automated code reviews

Fri, 24 Jul 2026 07:59:30 GMT

Datadog Code Security brings application-security findings into IDEs, continuous integration, and pull requests. For code reviews, its main capability is Static Code Analysis (SAST), which reports security vulnerabilities and code-quality problems before a change reaches production.

How Datadog helps during code review

Datadog Static Code Analysis scans source code for security vulnerabilities and quality problems before the code reaches production. Teams can run scans on Datadog’s infrastructure or in CI with the datadog-ci CLI. Datadog applies default language-specific rulesets, which teams can customize in the platform or in a code-security.datadog.yaml file.

During a code review, Datadog can:

Add inline comments for new SAST findings on pull requests in supported source-control systems.
Report code vulnerabilities separately from quality findings such as error-prone code, performance problems, style violations, and poor practices.
Provide deterministic or AI-generated suggested fixes when available.
Create status checks that teams can use as pull-request gates.
Associate findings with Datadog services and teams, helping route remediation work to an owner.

The current Datadog SAST documentation describes the supported languages, integrations, rules, and remediation options.

Pull-request comments and gates

Datadog supports inline SAST comments on cloud-hosted GitHub, GitLab, and Azure DevOps repositories. Teams can set minimum severity thresholds and exclude some lower-value findings, such as results in test files. Suggested fixes can be applied from a pull request when Datadog has a fix for the rule.

PR Gates are a separate enforcement mechanism. A gate can fail when modified lines introduce a new vulnerability or quality violation at a configured severity. Datadog creates the check, but the repository administrator must make that check required in GitHub or Azure DevOps before it blocks a merge. Gates can also use findings from software composition analysis, code coverage, infrastructure-as-code scanning, secret scanning, and flaky-test detection.

This focus on newly introduced problems is useful during review because an existing backlog does not have to block every pull request. See Datadog’s PR Gates documentation for the supported gate types and restrictions.

IDE feedback and remediation

Datadog extensions for Visual Studio Code and JetBrains IDEs can run static analysis while a developer edits code. That shortens the feedback loop by finding some violations before a pull request is opened.

For supported findings, Datadog distinguishes between deterministic fixes generated from rule templates and AI-suggested fixes for more complex violations. With the necessary GitHub App permissions, a developer can open a fix pull request from Datadog or commit a suggested fix to the current branch. These changes are proposals, not proof that a vulnerability is resolved; reviewers should inspect the patch and run the relevant tests.

Important limitations

Datadog’s pull-request comments and PR Gates are not supported for public repositories or for pull requests from a fork into a different repository. This makes the workflow a poor fit for many open-source projects.

Datadog Code Security is a broader platform rather than a lightweight standalone analyzer. It is strongest for organizations already using Datadog that want code findings, ownership, and production context in one system. A team that only needs a formatter, linter, or standalone static analyzer may find a smaller tool easier to operate.

Finally, static analysis only detects the patterns covered by its rules and analysis engines. It does not replace human review of requirements, design, business logic, tests, or operational risk.

Should you use Datadog for code review?

Datadog has a credible automated code-review workflow: SAST findings can reach developers in their IDE, CI pipeline, and pull requests, while gates can prevent selected new issues from being merged. The main reasons to choose it are its broader security coverage and its connection to Datadog’s service and runtime context.

If those capabilities are more than your team needs, compare the best automated code review tools or consider CodeQL for GitHub-native security scanning.

Official source for “Datadog Code Security for automated code reviews”: https://www.awesomecodereviews.com/automation/datadog-code-security/. Last updated: July 24, 2026

Overview of Code Review Research

Fri, 24 Jul 2026 08:59:30 GMT

A curated, evidence-aware map of research on modern code review, pull-request review, and closely related change-based inspection practices.

This list can also be found and contributed to on GitHub.

Papers are assigned to one primary topic to keep the list readable. Many papers are relevant to several topics; secondary topics are shown as tags.

Missing important research? Open a pull request and include the publication status, venue, study design and scope, and a one-sentence finding.

How to read this list

Publication status

PR — Peer-reviewed and published.
Accepted — Accepted by a peer-reviewed venue; the final issue or proceedings entry may still be pending.
Preprint — Public manuscript without confirmed peer-reviewed publication.
Grey literature — Industry analysis, blog post, report, or other non-peer-reviewed work.

Evidence profile

Citation count is not a measure of validity. This list therefore reports both the study design/scope and an approximate citation-influence band.

Common evidence profiles:

Systematic review — Synthesizes a defined body of prior research.
Large industrial study — Uses substantial data or deployment evidence from one or more companies.
Multi-project archival study — Analyses repositories, reviews, or pull requests across several projects.
Controlled experiment — Manipulates conditions to support stronger causal claims within the experimental setting.
Mixed methods — Combines quantitative and qualitative evidence.
Qualitative study — Interviews, observations, or qualitative analysis intended to explain mechanisms and experiences.
Tool or benchmark evaluation — Evaluates an automated technique, dataset, or model.

Citation influence

Citation bands are approximate snapshots checked in July 2026. Counts differ across Google Scholar, OpenAlex, Semantic Scholar, Scopus, and publisher pages, so they should be treated as a rough indicator of influence only. For a public repository, record one consistent source—preferably OpenAlex—and automate annual refreshes.

★★★★★ — 500+ citations
★★★★ — 200–499 citations
★★★ — 50–199 citations
★★ — 10–49 citations
★ — 1–9 citations
NEW — Too recent for citation count to be meaningful
— — Not checked

For maintainability, use one citation source consistently—preferably OpenAlex—and record the source and retrieval date in generated metadata.

Topic taxonomy

Topic	Main questions
Field overviews and taxonomies	What has been studied, how is the field structured, and where are the gaps?
Practices, process, and organizational context	How do teams perform code review, and how do practices differ across organizations?
Outcomes, effectiveness, and value	What does code review detect or improve, and under which conditions?
Reviewability, cognition, and change design	How do change size, ordering, tests, explanations, and presentation affect reviewers?
Reviewer selection, participation, workload, and latency	Who reviews, how quickly, and what affects participation or delays?
Human factors, communication, conflict, and inclusion	How do social dynamics, emotions, identity, and communication affect review?
Security-focused code review	Which security defects are detected or missed, and how can detection improve?
Static analysis, bots, and traditional automation	Which review tasks can be automated or supported without generative AI?
AI- and LLM-assisted code review	How well do LLM-based reviewers work, and how do they change human workflows?
Special contexts	How does code review work in research software, education, or other specific environments?

Recent peer-reviewed research: 2024–2026

These papers are separated because recent work may be highly relevant despite having few citations. “Recent” is based on publication years 2024–2026; online-first and proceedings dates can differ.

Field overviews and automation assessments

A Roadmap for Modern Code Review: Challenges and Opportunities — Yang et al., ACM Transactions on Software Engineering and Methodology, 2026. PR · Systematic roadmap · NEW · Tags: taxonomy, AI, future research. Consolidates research from 2013–2025 into understanding studies and improvement techniques, and identifies context-aware, value-driven, and human-centred directions for AI-era review.
Code Review Automation: Strengths and Weaknesses of the State of the Art — Tufano et al., IEEE Transactions on Software Engineering, 2024. PR · Comparative tool evaluation · ★★★ (~100) · Tags: automation, benchmarks, deep learning. Shows that automation performance varies substantially by task and evaluation setup, and that strong benchmark results do not by themselves establish production readiness.

AI- and LLM-assisted code review

AI-Assisted Assessment of Coding Practices in Modern Code Review — Vijayvergiya et al., AIware, 2024. PR · Large industrial deployment · ★★★ (~65) · Tags: LLM, coding practices, Google. Reports that an LLM-based reviewer can generate useful coding-practice comments at industrial scale, while requiring careful filtering, feedback loops, and integration into existing review workflows.
Deep Learning-Based Code Reviews: A Paradigm Shift or a Double-Edged Sword? — Tufano et al., ICSE, 2025. PR · Controlled experiment with 29 experienced developers and more than 50 review hours · ★★ (~17) · Tags: LLM assistance, attention, defect severity. LLM suggestions shifted reviewers’ attention toward suggested locations and increased detection of low-severity issues, but did not improve detection of high-severity issues, save time, or increase confidence.
Automated Code Review in Practice — Cihan et al., ICSE Software Engineering in Practice, 2025. PR · Multi-project industrial mixed methods · ★★ (~34) · Tags: LLM, adoption, outcomes. Across practitioner feedback and deployed projects, automated comments were frequently resolved and produced small quality gains, but also introduced irrelevant comments and did not automatically shorten review cycles.
Human and Machine: How Software Engineers Perceive and Engage with AI-Assisted Code Reviews Compared to Their Peers — Alami and Ernst, CHASE, 2025. PR · Qualitative study, 20 interviews · ★★ (~30) · Tags: trust, cognitive load, emotional load. Developers reported less emotional-regulation effort with LLM reviewers, but sometimes more cognitive load from verbose feedback; adoption remained constrained by trust and missing context.
Rethinking Code Review Workflows with LLM Assistance: An Empirical Study — Aðalsteinsson et al., ESEM Industry Track, 2025. PR · Industrial field study and experiment · NEW · Tags: workflow, trust, change complexity. Developers particularly valued AI-led review for large or unfamiliar changes, but false positives and insufficient repository context limited confidence and adoption.
Accountability in Code Review: The Role of Intrinsic Drivers and the Impact of LLMs — Alami et al., ACM Transactions on Software Engineering and Methodology, 2025. PR · Qualitative and conceptual study · ★★ (~19) · Tags: accountability, ownership, human–AI collaboration. Examines how intrinsic motivation and social responsibility support accountability in review and why replacing human interaction with LLM feedback can alter those mechanisms.
Benchmarking LLMs for Fine-Grained Code Review with Enriched Context in Practice — Hu et al., FSE Industry Track, 2026. PR · Benchmark of 67,910 context-enriched review instances plus industrial deployment · NEW · Tags: issue context, code context, LLM. Finds that textual context improves benchmark performance more than code context alone and that current models remain limited; at ByteDance, using the benchmark as a reward signal improved a self-evolving review tool’s measured performance by 61.98%.
SWR-Bench: Assessing LLM Performance in Real-World Code Review Comment Generation — Zeng et al., Proceedings of the ACM on Software Engineering, 2026. PR · Benchmark of 1,000 manually verified pull requests with full repository context · NEW · Tags: benchmark, repository context, LLM. Shows that current systems remain weak on realistic, context-rich review-comment generation; combining systems improves results but leaves substantial room below human-quality review.
RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-Based Code Review Automation at Atlassian — Tantithamthavorn et al., ICSE Software Engineering in Practice, 2026. PR · Large industrial online evaluation · ★ (~5) · Tags: LLM, deployment, cycle time. Reports that 38.7% of generated comments led to code changes, while observed pull-request cycle time fell by 30.8% and human review comments by 35.6% in the evaluated deployment context.
AI-Assisted Fixes to Code Review Comments at Scale — Maddila et al., FSE Industry Track, 2026. PR · 64,000-pair benchmark, randomized safety trial, and production deployment at Meta · NEW · Tags: LLM, automated fixes, deployment. An initial interface made reviewers more than 5% slower; showing suggestions only to authors removed that regression, and the deployed model reached a 19.7% actionable-to-applied rate—9.2 percentage points above GPT-4o.
Engagement in Code Review: Emotional, Behavioral, and Cognitive Dimensions in Peer vs. LLM Interactions — Alami and Ernst, ACM Transactions on Software Engineering and Methodology, 2026. PR · Human-centred empirical study · NEW · Tags: engagement, cognition, emotion. Frames review engagement as cognitive, emotional, and behavioural, showing that peer and LLM interactions create materially different forms of effort and participation.
Toward Author-Guided Review: An Agentic Architecture for Reflective Code Review — Davila and Wiese, AGENT, 2026. PR · Prototype architecture · NEW · Tags: agents, reflection, orchestration. Proposes a multi-agent review architecture intended to improve reasoning and self-correction; evidence remains early-stage until independently evaluated in realistic development settings.

Human factors and review content

Understanding and Effectively Mitigating Code Review Anxiety — Lee et al., Empirical Software Engineering, 2024. PR · Observational model plus randomized waitlist-controlled intervention · ★★ (~13) · Tags: anxiety, avoidance, intervention. Finds that anxiety is strongly associated with avoidance behaviours such as procrastination and rubber-stamping, and provides initial experimental evidence that a brief cognitive-behavioural workshop can reduce code-review anxiety.
Explaining Explanations: An Empirical Study of Explanations in Code Reviews — Widyasari et al., ACM Transactions on Software Engineering and Methodology, 2025. PR · Empirical repository study · ★★ (~21) · Tags: rationale, comments, comprehension. Shows that explanations are an important but unevenly supplied part of review feedback, motivating tools and practices that help reviewers communicate reasons rather than only requested changes.
A Qualitative Study on Refactorings Induced by Code Review — Coelho et al., Empirical Software Engineering, 2025. PR · Qualitative repository study · ★★ (~10) · Tags: refactoring, maintainability, review comments. Characterizes why reviewers request refactorings and how review-triggered refactoring contributes to maintainability beyond direct defect correction.
The Interaction of Complexity and Provenance in Code Review Decisions: Evidence from a Controlled Experiment — Singh et al., FSE, 2026. PR · Between-subjects experiment with 385 participants · NEW · Tags: complexity, AI provenance, automation bias. Higher code complexity increased acceptance of incorrect revisions; provenance alone had no main effect, but under high complexity reviewers were more likely to accept incorrect revisions labelled as AI-authored.
Assessing Harmful Comments and Specificity in Code Review Feedback at Scale Using Large Language Models — You et al., FSE Industry Track, 2026. PR · More than 204,000 feedback threads from 30 OSS repositories plus data from 45 organizations · NEW · Tags: feedback quality, harmful comments, specificity, LLM. LLM classifiers reached F1 up to 0.83 for sentiment and 0.67 for specificity; harmful comments were rare, while specificity analysis proved more immediately useful in industrial deployment.

Reviewer selection and risk-aware workflows

Mitigating the Risk of Defects and Improving Knowledge Distribution with Code Reviewer Recommenders — Sefidi Esfahani and Rigby, FSE, 2026. PR · Repository analysis and simulation · NEW · Tags: reviewer recommendation, defect risk, knowledge distribution. Introduces a team-level changeset-safety measure and simulates adding an expert to risky pull requests; the strategy improves modeled defect-finding effectiveness while balancing workload and knowledge distribution, but the outcome is simulated rather than a live causal deployment.
Code Reviewer Recommendation for High Risk Diffs at Scale: Workflow, Recommender, and Live Experiments — Paraspatki et al., FSE Industry Track, 2026. PR · Two randomized industrial trials covering more than 20,000 high-risk diffs · NEW · Tags: risk-aware review, reviewer recommendation, A/B test. A dedicated high-risk workflow increased review depth and reduced final risk classifications by 9.56% with a 0.45% review-time increase; a tailored recommender produced 9.94% more comments and 7.77% more acceptances without significant guardrail regressions.

Security

An Empirical Study of Static Analysis Tools for Secure Code Review — Charoenwet et al., ISSTA, 2024. PR · 319 vulnerabilities and 815 vulnerability-contributing commits across 92 C/C++ projects · ★★★ (~88) · Tags: static analysis, secure review, prioritization. Finds that tested static-analysis tools can surface useful warnings for some vulnerable changes, but at least 76% of warnings were irrelevant and 22% of vulnerable changes were missed; prioritization improved precision and recall only modestly.
Toward Effective Secure Code Reviews: An Empirical Study of Security-Related Coding Weaknesses — Charoenwet et al., Empirical Software Engineering, 2024. PR · Case study of OpenSSL and PHP using 135,560 review comments · ★★ (~25) · Tags: security, coding weaknesses, remediation. Reviewers raised concerns covering 35 of 40 CWE-699 categories, but only about 37% were fixed in the same review and some changes were merged despite unresolved security concerns.
SeRe: A Security-Related Code Review Dataset Aligned with Real-World Review Activities — Zhao et al., ICSE, 2026. Accepted at ICSE · Dataset of 6,732 security-related reviews selected from 373,824 review instances · NEW · Tags: security, dataset, multilingual repositories. Provides a curated benchmark for security-specific review classification and generation, while its value for production effectiveness still requires downstream validation.

Emerging, not-yet-peer-reviewed work from 2024–2026

These manuscripts are current and potentially useful, but should not be presented as established evidence until peer review, replication, and stable publication metadata are available.

A Survey of Code Review Benchmarks and Evaluation Practices in Pre-LLM and LLM Era — 2026. Preprint · Systematic survey of 99 papers · NEW · Tags: benchmarks, evaluation, LLM. Compares 58 pre-LLM and 41 LLM-era studies across five domains and 18 tasks and highlights fragmentation in datasets, metrics, and evaluation protocols.
Evaluating Large Language Models for Code Review — 2025. Preprint · Comparative model evaluation · NEW · Tags: correctness classification, repair, context. Reports best-case scores of 68.50% for issue classification and 67.83% for correction, with performance dropping when issue descriptions are absent; the results support human-in-the-loop use rather than autonomous acceptance.

Established peer-reviewed research

1. Field overviews and taxonomies

A Systematic Literature Review and Taxonomy of Modern Code Review — Davila and Nunes, Journal of Systems and Software, 2021. PR · Systematic review of 139 papers · ★★★ (~70–125) · Tags: taxonomy, research methods. Organizes the field into foundational studies, proposals, and evaluations and provides a strong starting point for discovering earlier work.
Modern Code Reviews—Survey of Literature and Practice — Badampudi et al., ACM Transactions on Software Engineering and Methodology, 2023. PR · Review of 244 primary studies plus practitioner survey · ★★★ (~80) · Tags: synthesis, research–practice gap. Identifies five major research themes and shows that practitioners value quality and process outcomes more consistently than human-factor or support-system claims.
A Faceted Classification Scheme for Change-Based Industrial Code Review Processes — Baum et al., QRS, 2016. PR · Classification grounded in industrial processes · ★★★ (~73) · Tags: process design, industry. Defines dimensions for comparing change-based review processes instead of treating “code review” as one uniform practice.

2. Practices, process, and organizational context

Expectations, Outcomes, and Challenges of Modern Code Review — Bacchelli and Bird, ICSE, 2013. PR · Microsoft mixed methods · ★★★★★ (~500+) · Tags: motivations, knowledge transfer, challenges. Shows that defect finding is the stated primary motivation, while understanding, knowledge transfer, team awareness, and finding alternative solutions are major practical outcomes.
Process Aspects and Social Dynamics of Contemporary Code Review — Bosu et al., IEEE Transactions on Software Engineering, 2017. PR · Comparative Microsoft and OSS study · ★★★ · Tags: process, social dynamics, industry–OSS comparison. Demonstrates that review outcomes and participation are shaped by both process design and social relationships, with meaningful differences between company and open-source settings.
Code Reviewing in the Trenches: Understanding Challenges, Best Practices and Tool Needs — MacLeod et al., IEEE Software, 2018. PR · Industrial interviews and observations · ★★★ · Tags: reviewer needs, tools, practice. Identifies recurring practical difficulties including understanding changes, finding suitable reviewers, managing context, and communicating effectively.
Modern Code Review: A Case Study at Google — Sadowski et al., ICSE Software Engineering in Practice, 2018. PR · Large industrial study: interviews, survey, and 9 million reviewed changes · ★★★★★ (~560) · Tags: Google, process, scale. Documents Google’s lightweight review process, review norms, tooling, and motivations at very large organizational scale.
Code Review Is Just Reviewing Code? A Qualitative Study to Understand the Activities Developers Perform During Code Review — Cunha et al., SBES, 2021. PR · Qualitative study · ★★ (~26) · Tags: activities, collaboration, sensemaking. Shows that review includes coordination, learning, design discussion, and process work in addition to inspecting code.
Developers’ Perception of Peer Code Review in Research Software Development — Eisty and Carver, Empirical Software Engineering, 2022. PR · Survey of research-software developers · ★★ (~41) · Tags: research software, adoption, perceived value. Finds broad perceived value in peer review but also context-specific barriers involving expertise, resources, and the less standardized nature of research-software teams.
Using a Balanced Scorecard to Identify Opportunities to Improve Code Review Effectiveness — Hasan et al., Empirical Software Engineering, 2021. PR · Industrial experience report · ★★ · Tags: measurement, process improvement, dashboards. Describes a multi-dimensional measurement approach for identifying review bottlenecks and selecting improvement initiatives rather than optimizing a single metric.

3. Outcomes, effectiveness, and value

The Impact of Code Review Coverage and Code Review Participation on Software Quality — McIntosh et al., MSR, 2014. PR · Multi-project archival study · ★★★ · Tags: coverage, participation, defects. Reports associations between lower review coverage or participation and poorer post-release quality; the observational design supports association, not a simple causal claim.
Modern Code Reviews in Open-Source Projects: Which Problems Do They Fix? — Beller et al., MSR, 2014. PR · Manual classification of more than 1,400 changes · ★★★★ (~350) · Tags: defects, maintainability, OSS. Finds that review addresses a broad mixture of functional defects, evolvability concerns, and other issues rather than only correctness bugs.
Characteristics of Useful Code Reviews: An Empirical Study at Microsoft — Bosu et al., MSR, 2015. PR · Microsoft mixed methods · ★★★ · Tags: useful comments, change size, reviewer experience. Identifies factors associated with useful comments and reports that reviews spanning more files tend to contain a lower proportion of useful feedback.
Why Does Code Review Work for Open Source Software Communities? — Alami et al., ICSE, 2019. PR · Qualitative study · ★★★ (~59) · Tags: mechanisms, community, trust. Explains review effectiveness through community mechanisms such as accountability, transparency, shared ownership, and relationship building—not only defect detection.
Do Small Code Changes Merge Faster? A Multi-Language Empirical Investigation — Catolino et al., MSR, 2022. PR · Multi-project archival study · ★★ (~16) · Tags: size, latency, pull requests. Contrary to common advice, finds no consistent relationship between pull-request size or composition and time to merge in the studied projects.
Nudge: Accelerating Overdue Pull Requests Toward Completion — Kudrjavets et al., ACM Transactions on Software Engineering and Methodology, 2023. PR · Large industrial intervention · ★★ (~49) · Tags: latency, reminders, workflow. Reports that targeted automated reminders reduced resolution time for overdue pull requests by roughly 60% in the evaluated deployment.

4. Reviewability, cognition, and change design

When Testing Meets Code Review: Why and How Developers Review Tests — Spadini et al., ICSE, 2018. PR · Mixed methods · ★★★ (~92) · Tags: tests, reviewer attention, practices. Shows that developers do review tests, but test review receives uneven attention and involves concerns that differ from production-code review.
Test-Driven Code Review: An Empirical Study — Spadini et al., ICSE, 2019. PR · Controlled experiment · ★★★ · Tags: review order, tests, defects. Reviewing tests before production code led participants to find more test-code defects and fewer maintainability issues in production code, while the number of production-code defects found did not materially change.
What Makes a Code Change Easier to Review: An Empirical Investigation on Code Change Reviewability — Baum et al., ESEC/FSE, 2018. PR · Multi-method empirical study · ★★★ · Tags: reviewability, change description, complexity. Identifies technical and presentation characteristics that affect perceived review difficulty, supporting reviewability as a broader construct than change size alone.

Primers or Reminders? The Effects of Existing Review Comments on Code Review — Spadini, Çalikli, and Bacchelli, ICSE, 2020. PR · Controlled experiment with 85 developers · ★★ · Tags: cognitive bias, existing comments, defect detection. Although approximately 70% of participants showed susceptibility to availability bias, existing comments did not generally bias review outcomes; comments about unusual bug types increased detection of another bug of the same type without reducing detection of unrelated bugs.

First Come First Served: The Impact of File Position on Code Review — Fregnan et al., ESEC/FSE, 2022. PR · Large repository study plus controlled experiment · ★★ · Tags: ordering, attention, cognition. Shows a strong position effect: in the experiment, a defect had substantially lower odds of detection when its file appeared last rather than first.
An Exploratory Study on Confusion in Code Reviews — Ebert et al., Empirical Software Engineering, 2021. PR · Qualitative and repository study · ★★★ · Tags: confusion, comprehension, communication. Characterizes signals and causes of reviewer confusion and shows that unresolved misunderstanding can lengthen discussions and impede review progress.

5. Reviewer selection, participation, workload, and latency

Impact of Developer Reputation on Code Review Outcomes in OSS Projects — Bosu and Carver, ESEM, 2014. PR · Multi-project archival study · ★★★ · Tags: reputation, acceptance, latency. Finds that contributor reputation is associated with acceptance, feedback speed, completion time, and the number of patch sets required.
Impact of Peer Code Review on Peer Impression Formation: A Survey — Bosu and Carver, ESEM, 2013. PR · Survey · ★★ · Tags: trust, reputation, social judgment. Shows that review interactions shape developers’ impressions of one another, linking technical review behaviour to future collaboration and trust.
Does Reviewer Recommendation Help Developers? — Thongtanunam et al., IEEE Transactions on Software Engineering, 2020. PR · Tool evaluation and practitioner study · ★★★ (~70) · Tags: reviewer recommendation, adoption, evaluation. Finds that recommendations were often perceived as relevant but rarely added practical value beyond developers’ existing knowledge, showing that offline accuracy alone is an insufficient evaluation criterion.
Code Reviewer Recommendation in Tencent: Practice, Challenge, and Direction — Rong et al., ICSE Software Engineering in Practice, 2022. PR · Large industrial comparison · ★★ (~15) · Tags: reviewer recommendation, Tencent, deployment. Compares established recommendation approaches in a production environment and identifies practical constraints—such as organizational structure, workload, and maintainability—that offline benchmarks often omit.
Recommending Code Reviewers for Proprietary Software Projects: A Large Scale Study — Rong et al., SANER, 2022. PR · Large industrial study at Tencent · ★★ (~18) · Tags: reviewer recommendation, proprietary software, scale. Evaluates reviewer-recommendation techniques on proprietary projects and introduces CAMP, showing that production constraints and organizational context materially affect recommendation usefulness.

6. Human factors, communication, conflict, and inclusion

Interpersonal Conflicts During Code Review: Developers’ Experience and Practices — Wurzel Gonçalves et al., Proceedings of the ACM on Human-Computer Interaction, 2022. PR · Interviews with 22 developers · ★★ (~26) · Tags: conflict, coping, communication. Characterizes conflict causes, consequences, and developer coping strategies, showing that conflicts can damage relationships and participation even when the technical issue is resolved.
Predicting Developers’ Negative Feelings About Code Review — Egelman et al., ICSE, 2020. PR · Large industrial mixed methods · ★★★ (~83) · Tags: negative experience, prediction, organizational climate. Connects review-process and interaction signals with developers’ negative experiences, enabling teams to study socio-technical review health rather than only throughput.
The Pushback Effects of Race, Ethnicity, Gender, and Age in Code Review — Murphy-Hill et al., Communications of the ACM, 2022. PR · Large industrial observational study · ★★ · Tags: demographics, pushback, inclusion. Reports that the amount of pushback authors receive varies with demographic characteristics, while emphasizing that these observational differences require organizational investigation rather than assumptions about individual performance.
Engineering Impacts of Anonymous Author Code Review — Murphy-Hill et al., IEEE Transactions on Software Engineering, 2022. PR · Industrial field experiment, 5,217 reviews and 300 engineers · ★★ (~18) · Tags: anonymity, bias mitigation, outcomes. Tests anonymous-author review in practice and provides direct experimental evidence about its engineering and behavioural effects rather than relying only on observational demographic comparisons.
Systemic Gender Inequities in Who Reviews Code — Egelman et al., Proceedings of the ACM on Human-Computer Interaction, 2023. PR · Large industrial mixed methods · ★★ (~14) · Tags: reviewer workload, gender, recommender systems. Finds that women performed about 25% fewer reviews on average and traces the difference to reviewer choice, recommender-system amplification, and unequal access to reviewer credentials.
Code Reviews in Open Source Projects: How Do Gender Biases Affect Participation and Outcomes? — Sultana et al., Empirical Software Engineering, 2023. PR · 1,010 projects across 14 datasets · ★★ (~32) · Tags: gender, participation, acceptance, latency. Finds widespread but context-dependent gender differences; reviewer participation was the most consistently unequal outcome, while the direction of acceptance and latency differences varied across communities.
Expressions of Sentiments During Code Reviews: Male vs. Female — Paul et al., SANER, 2019. PR · Multi-project archival study · ★★ · Tags: sentiment, gender, communication. Reports gender-associated differences in positive and negative sentiment expression across six open-source review communities, while not establishing that sentiment differences are caused by gender.
Biases and Differences in Code Review Using Medical Imaging and Eye-Tracking: Genders, Humans, and Machines — Huang et al., ESEC/FSE, 2020. PR · Controlled eye-tracking and neuroimaging study · ★★ · Tags: attention, gender, automation bias. Finds measurable differences in review attention and evaluation behaviour across participant and code-provenance conditions, illustrating that review judgments can be influenced by factors beyond code content.
Automated Identification of Toxic Code Reviews Using ToxiCR — Sarker et al., ACM Transactions on Software Engineering and Methodology, 2023. PR · Labelled dataset and classifier evaluation · ★★★ (~80) · Tags: toxicity, NLP, tooling. Introduces a software-engineering-specific toxicity taxonomy, dataset, and classifier that outperforms general-purpose toxicity detectors on code-review text.
Gender Differences and Bias in Open Source: Pull Request Acceptance of Women Versus Men — Terrell et al., PeerJ Computer Science, 2017. PR · Large multi-project archival study of roughly 3 million pull requests · ★★★★★ · Tags: gender, acceptance, identity visibility. Women’s pull requests had higher acceptance rates overall, but among external contributors whose gender was identifiable, women’s contributions were accepted less often than men’s; this difference was not observed when gender was not identifiable.
Investigating the Effects of Gender Bias on GitHub — Imtiaz et al., ICSE, 2019. PR · Large-scale quantitative GitHub study · ★★★ · Tags: gender, communication, participation. Finds little direct evidence of the four investigated gender-bias effects in observable GitHub outcomes, but reports that women concentrated their work in fewer repositories and communicated more restrainedly than men.
On the Relationship Between the Developer’s Perceptible Race and Ethnicity and the Evaluation of Contributions in OSS — Nadri et al., IEEE Transactions on Software Engineering, 2022. PR · Large multi-project archival study of more than 2 million pull requests · ★★★ · Tags: race, ethnicity, acceptance, affinity bias. Contributions from developers perceived as White had approximately 6–10% higher odds of acceptance than contributions from developers perceived as non-White; non-White contributors also had better acceptance odds when the integrator was perceived as belonging to the same racial or ethnic group.

7. Security-focused code review

Identifying the Characteristics of Vulnerable Code Changes: An Empirical Study — Bosu et al., FSE, 2014. PR · Empirical security study · ★★★ · Tags: vulnerable changes, risk factors, targeting. Characterizes change properties associated with vulnerability introduction to help teams target scarce security-review attention.
A Security Perspective on Code Review: The Case of Chromium — Bosu et al., SCAM, 2016. PR · Chromium archival study · ★★★ · Tags: security review, vulnerabilities, reviewer expertise. Examines how security concerns appear in Chromium review and how reviewer participation and change characteristics relate to security outcomes.
A Large-Scale Study of Modern Code Review and Security in Open Source Projects — Thompson and Wagner, PROMISE, 2017. PR · 3,126 projects, 143 languages, 489,038 issues, and 382,771 pull requests · ★★★ (~53) · Tags: security, review coverage, OSS. Finds associations between modern review practices and security-related outcomes at large scale, while the observational design does not establish that review alone caused those outcomes.
Why Don’t Developers Detect Improper Input Validation? '; DROP TABLE Papers; — Braz et al., ICSE, 2021. PR · Controlled online experiment with 146 participants · ★★ (~38) · Tags: input validation, threat framing, warnings. Finds that making an attack scenario visible and providing security warnings improves detection of improper input validation during review.
Why Security Defects Go Unnoticed During Code Reviews? A Case-Control Study of the Chromium OS Project — Paul et al., ICSE, 2021. PR · Case-control study: 516 detected and 374 escaped defects · ★★/★★★ (~36–60) · Tags: escaped defects, workload, review history. Identifies factors associated with detection and escape, including reviewer load, change spread, mutual-review relationships, and prior file history.
Software Security During Modern Code Review: The Developer’s Perspective — Braz and Bacchelli, ESEC/FSE, 2022. PR · 10 interviews plus survey of 182 developers · ★★ · Tags: security mindset, expertise, process. Shows that developers often treat security as implicit or specialist work and identifies gaps in security knowledge, training, process, and tooling that prevent security from becoming a routine review concern.

8. Static analysis, bots, and traditional automation

Evaluating How Static Analysis Tools Can Reduce Code Review Effort — Panichella et al., VL/HCC, 2017. PR · Comparative empirical study · ★★★ (~114) · Tags: static analysis, reviewer effort, overlap. Finds that an off-the-shelf static analyser detected about 16% of issues raised manually, with additional potential from project-specific rules; this supports complementing rather than replacing human review.
Towards Automating Code Review Activities — Tufano et al., ICSE, 2021. PR · Neural-model evaluation · ★★★ · Tags: comment generation, code transformation, automation. Demonstrates the feasibility of learning selected review activities from historical data while exposing substantial limitations in generalisation and complete end-to-end automation.
Using Pre-Trained Models to Boost Code Review Automation — Tufano et al., ICSE, 2022. PR · Large model evaluation · ★★★★ (~306) · Tags: pre-trained models, comment generation, code changes. Shows that pre-training substantially improves automated review-comment and code-change tasks compared with models trained only on task-specific review data.
Investigating the Effects of Code Review Bots on Pull Request Activities — Wessel et al., Empirical Software Engineering, 2022. PR · 1,194 projects plus 12 interviews · ★★ (~41) · Tags: bots, communication, pull-request outcomes. Associates bot adoption with more merged and fewer abandoned pull requests, while also finding reduced human communication and new integration challenges.
Can Static Analysis Tools Find More Defects? A Qualitative Study of Design Rule Violations Found by Code Review — Lenarduzzi et al., Empirical Software Engineering, 2023. PR · Qualitative classification of 1,323 review defects · ★★ · Tags: static analysis, design rules, automation potential. Finds that many review findings map to rules that static analysis could potentially encode, but theoretical detectability should not be interpreted as demonstrated precision and recall in live review.

Historical foundations and adjacent evidence

These works are useful for understanding modern code review but should not be mixed uncritically with contemporary asynchronous, tool-mediated review.

An Exploratory Study of the Pull-Based Software Development Model — Gousios et al., ICSE, 2014. PR · Large multi-project archival study · ★★★★★ (~900) · Tags: pull requests, integration, participation. Establishes foundational evidence about pull-request contribution, evaluation, integration time, and community participation.
The Effect of Familiarity Between Author and Reviewers on the Effectiveness of Code Inspection Meetings — 1999. Dissertation/non-journal source · Historical inspection study · — · Tags: familiarity, synchronous inspection. Examines how prior familiarity may affect traditional inspection meetings; applicability to modern asynchronous review should be treated cautiously.

Grey literature and quantitative industry analyses

Keep these in a separate section. They may offer useful scale or practitioner hypotheses, but their sampling, analysis, and review procedures usually provide weaker safeguards than peer-reviewed research.

Does Size Matter in Pull Requests? Insights from 30K Developers — Adadot, 2023. Grey literature · Proprietary quantitative analysis · Tags: size, latency, developer analytics. Reports associations between pull-request size and process outcomes, but should be interpreted alongside the peer-reviewed multi-language study that found no consistent size–merge-time relationship.

Recommended contribution format

Use this format for each pull request:

- [Paper title](canonical DOI or publisher URL) — Author et al., *Venue*, year. **Status · Evidence profile and sample/scope · Citation band · Tags.** One sentence stating the principal finding without implying causality beyond the study design.

Required checks:

Use the canonical DOI or official publisher page where possible.
Verify the publication year, venue, and peer-review status.
State the actual design and scope—for example, “single-company archival study,” not merely “empirical study.”
Distinguish observed association from demonstrated causal effect.
State null findings explicitly.
Do not describe benchmark performance as evidence of production effectiveness.
Do not describe citation count as evidence quality.
Add a citation-source and retrieval-date field if counts are generated automatically.
Re-check the “Recent” sections at least annually and move older work into the topic taxonomy.

Official source for “Overview of Code Review Research”: https://www.awesomecodereviews.com/research/code-review-research-overview/. Last updated: July 24, 2026

Stacked Pull Requests - The Complete Guide for Developers

Wed, 17 Sep 2025 13:22:11 GMT

This post explains the concepts, workflows, and tools behind stacked pull requests (stacked PRs).

In a nutshell, with stacked pull requests we split a large feature into several smaller, coherent changes that build on one another so they can be independently reviewed and then merged in dependency order.

Why Stacked Pull Requests?

Code reviews are essential for software quality—but let’s be honest: they’re also one of the biggest bottlenecks in modern development.

Often, authors get stuck waiting for feedback, thus losing valuable momentum. The reason for long waiting times (and also inefficient code reviews), are often large PRs. Large PRs mean that reviewers struggle with understanding the multiple, and complex changes that are often within one PR.

The outcome?

Slow development cycles
Higher risk of bugs
Frustrated teams

Stacked PRs offer a way out. By structuring your work as a stack of smaller, dependent PRs, you can:

Keep development flowing without waiting on merges

Make code reviews shorter, clearer, and more effective

Reduce the cognitive load for reviewers

Build higher-quality software, faster

What Does Research Say?

There is empirical support for decomposing large changes, but the results are more nuanced than “smaller is always faster.” A controlled experiment with 28 developers compared one tangled pull request with the same change split into two logically coherent pull requests. Reviewers of the decomposed change reported fewer false-positive issues and approached the review differently. However, they did not find significantly more defects, finish faster, or understand the change rationale better.

This supports the central idea behind stacked PRs: separate different concepts into coherent review units. It does not mean that stacking automatically guarantees faster or higher-quality reviews. The quality of the decomposition, the reviewer, and the surrounding workflow still matter.

Typical Feature-Branch Workflow

Before looking at stacked-PRs, let’s quickly recap how a typical feature-branch workflow looks like. In a feature-branch workflow, you would start with a feature you want to implement, and create one new branch for said feature. Then, you make several changes (commits) to this branch, and once you finished your feature, you ask your colleagues to review the changes by opening one PR.

main
 \
  feature

Such traditional feature-branch workflows often lead to long-lived branches that diverge from main for days or weeks. And it also means code reviews only happen once the feature is deemed complete and ready for review. Code reviews usually happen only once the feature is considered complete, which delays feedback. The longer a branch lives, the harder it becomes to keep in sync, the greater the risk of painful merge conflicts, and the more difficult the review process itself becomes.

The Stacked PR Workflow

In a stacked-PR workflow, you instead start by thinking about how you can split the feature into several coherent subtasks (think divide-and-conquer strategy).

Here we also follow the single responsibility principle, which is not only relevant when we design a software system, but also helpful as a principle for how we work.

This means that once we identified subtask of our task, we create new branches for each of the subtasks that we identified. It’s important to know that this also means that the branches are dependent on each other. This means, only the first branch is branched out of main. All the other branches, are branched out from the last subtask they depend on.

main
 \
  subtask-1
   \
    subtask-2
     \
      subtask-3

Such a stacked-PR approach can keep changes smaller and branches shorter-lived—provided the bottom of the stack is integrated frequently. It also creates more focused review units and enables feedback to start before the complete feature is finished.

In other words, stacked PRs nudge teams closer to the benefits of trunk-based development—without giving up the clarity and safety of code review.

Did you know that Meta develops Sapling, a Git-compatible source control system with first-class support for stacked commits and submitting them as GitHub pull requests?

Feature-Branch Workflow

Start working on the complete feature.
Branch off `main` once to create one branch for this feature.
Make all the changes needed to complete the feature on this one branch.
Open one, often large PR.
Wait for review, and approval.
Merge the feature branch back into main.
Only then start new dependent work.

In a feature-branch based workflow, every new (dependent) piece of work is blocked by the review and merge of the previous PR. If reviews are slow—or PRs are large—development gets bottlenecked.

Stacked-PR Workflow

Split the feature into smaller, coherent subtasks.
Branch off `main` for the first subtask.
Open a PR for that subtask.
Immediately branch from that branch (not main) for the next subtask.
Open a PR for the second subtask, which depends on the first.
Repeat for all further subtasks, creating a stack of PRs.

In a stacked-PR workflow, reviewers now see a sequence of smaller, focused PRs. Once the bottom PR is approved and merged, the stack syncs, and the next PR in line is ready to go.

Example: Stacked PRs in Action

Imagine we’re working on a customer support system, and we want to add a new feature to our AI phone call bot: the ability to ask customers for their telephone number.

Instead of stuffing all changes into one branch and opening a 1,000-line or more PR, we start by splitting the work into smaller, coherent subtasks.

One way is to break down the feature itself according to our layered architecture: database, business logic, and UI changes:

Database layer
- Create a new branch fb-database on top of branch develop
- Implement database changes
- Open a PR for this work
Business logic
- Create a branch fb-business-logic on top of fb-database
- Implement the feature logic
- Open a PR for this work
UI layer
- Create a branch fb-ui on top of fb-business-logic
- Implement the UI changes
- Open a PR for this work

Because each branch builds on the last, the full feature is always present locally. But reviewers only see the incremental change in each PR.

This makes reviews easier: reviewers can focus on one coherent piece at a time, which helps them build a better mental model and provide higher-quality feedback.

One commit per PR?

Some workflows or tools (like Google’s Critique or Gerrit) review each commit as a separate change, which enforces a strict separation of changes. Gerrit also supports stacking commits so they can be reviewed individually and submitted together. While this can be useful, a branch-based stacked PR does not have to contain only one commit—you can choose the level of granularity that works best for your team.

Manually Stacking PRs

If you want to start using stacked-PRs right away and are using a Git based version control system, then you do not need anything else than a couple of native Git commands, some practice of breaking up work into smaller subtasks, and quite a bit of patience for syncing changes and handling merge conflicts.

I describe all the commands, as well as merge and rebase strategies for this in this blog post about manually stacking PRs.

Yet, because Git was not designed for this workflow, the day-to-day work with manually stacked PRs means you have to painfully rebase or merge every branch and resolve cascading conflicts, which often requires a lot of time-consuming, tedious, and error-prone workarounds. This limits the gains developers get from a stacked-based workflow.

Fortunately, over the last years, several tools have been created that ease usage of stacked-PRs workflows.

So, let’s look at them!

Tool-Support for Stacked PRs

Modern tools like Graphite, ghstack, git-spice, Git Town, SPR, Sapling, and Aviator automate much of this process, making stacked PRs practical for day-to-day development.

Sapling by Meta

Sapling is Meta’s open-source, cross-platform, and highly scalable source control system. It is compatible with Git repositories, but unlike a typical Git workflow, it can represent a stack as a sequence of commits without requiring a named branch for every change.

With sl pr submit, Sapling creates or updates one GitHub pull request for every commit in the local stack. These are overlapping PRs that all target the main branch. Sapling therefore also provides ReviewStack, a review interface designed to display this type of stack more clearly.

SPR

SPR is an open source CLI tool that allows you to create and manage stacked pull requests. The approach behind SPR is that each commit (yes each commit) becomes its own pull request. While this might seem excessive for you, this is also how tools like Gerrit or Critique work, which are used by Google, and lead to smaller, more focused PRs. When using SPR, you do not have to create new branches. Instead, you create one branch, and then commit your work, subtask, by subtask to the branch. SPR takes care of opening up PRs for each of the commits, while using the commit message as the PR title. It’s important that you keep using the tool for merging, as otherwise, you could end up merging changes together in an order that probably makes no sense.

ghstack

ghstack also uses a commit-based model: you prepare a series of commits and it submits each commit as a separate GitHub pull request. It uses synthetic base and head branches so that every PR shows only its own incremental change, and stacks must be landed with ghstack land rather than the normal GitHub merge button.

Recent versions can optionally use Claude or Codex to generate descriptions for stack updates. For an existing PR, the agent receives the interdiff—the change since the last submitted version—rather than the entire PR.

git-spice

git-spice is an open-source tool for creating, navigating, restacking, and submitting stacks of Git branches. Unlike several GitHub-specific tools, it supports pull or merge requests across GitHub, GitLab, Bitbucket, Gitea, and Forgejo. It also works locally without an external service until you push or pull from a remote repository.

Git Town

Git Town provides additional Git commands for creating, synchronizing, shipping, and cleaning up branches. It’s compatible with branching models like GitHub Flow, Git Flow, GitLab Flow, and trunk-based development.

For stacked changes, Git Town can append or prepend branches, change parent relationships, reorder or combine adjacent branches, and detach a branch from a stack. It also automates the tedious work of keeping the stack synchronized with git town sync.

Aviator

Aviator’s open-source CLI manages parent-child relationships between GitHub pull requests, synchronizes dependent branches, and integrates stacks with a stack-aware merge queue.

Aviator has also started connecting stacked PRs directly with agentic development. Its agent plugin teaches coding agents to use the stack-aware av branch, av pr, and av sync commands instead of raw Git operations. Aviator Runbooks can execute a larger task in steps and produce one stacked PR per step, giving human reviewers incremental checkpoints instead of one large agent-generated change.

Graphite

Graphite builds on top of Git and integrates with GitHub. Its workflow packages small changes as stacked PRs that can be created with a CLI and reviewed in a dedicated web interface. Graphite also provides a stack-aware merge queue that lands approved changes in the correct order.

In December 2025, Graphite announced that it was joining Cursor while continuing to operate as an independent product. The integration now brings agent-generated pull requests into the same review and merge environment, while Graphite continues to invest in its stacked-PR workflow.

Stacked PRs in Agentic Development

Stacked PRs can be particularly useful when a coding agent is working on a large task whose parts genuinely depend on one another. A stack turns the agent’s output into bounded review units: for example, a schema change, followed by service logic, followed by the UI. Reviewers can validate the foundation before approving the layers built on top of it.

However, agent-generated work should not be stacked merely because several agents are working in parallel. Independent tasks are usually better handled as independent branches and PRs. A stack is most useful when it represents a real dependency chain and a coherent review narrative.

Early research on agent-authored pull requests reinforces the importance of keeping those review units manageable, but does not yet prove that stacked agent PRs outperform monolithic ones. A 2026 empirical study found that larger agent-authored changes and force pushes were associated with a lower likelihood of merging, while reviewer engagement had the strongest relationship with successful integration. Another 2026 study of review activity found that many agent-authored PRs had no recorded review and that review comments were often produced by other agents. Splitting work into a stack can improve reviewability, but it does not by itself guarantee human oversight.

For agent-generated stacks, keep the stack shallow, give each PR one clear purpose, use stack-aware tooling to avoid cascading rebases, and make a human author responsible for reviewing each layer before requesting review from others.

Summary

Stacked pull requests allow developers to break large, hard-to-review changes into a series of smaller, dependent PRs. Instead of waiting for one PR to merge before starting the next, developers can keep working by branching on top of previous work. Reviewers benefit from focused, incremental changes that are easier to understand and provide feedback on. While managing stacked PRs manually can be tedious, modern tools like Graphite, ghstack, git-spice, SPR, Git Town, Sapling, and Aviator automate much of the workflow. Used for genuine dependency chains, stacks can enable earlier feedback and smoother collaboration without requiring reviewers to digest one monolithic change.

Feature-Branch Workflow

One branch for the whole feature
One often large PR
Blocked until review + merge

Downside: Long-lived branches, big PRs, delayed integration.

Stacked-PR Workflow

Multiple short-lived branches
Each subtask has its own PR
Parallel development + review

Potential benefit: Earlier feedback, less context switching, and changes that stay closer to main.

If your team is struggling with large PRs, painful reviews, or stale feature branches, give stacked PRs a try.

👉 Your future self (and your reviewers) will thank you.

So, happy stacking!

Official source for “Stacked Pull Requests - The Complete Guide for Developers”: https://www.awesomecodereviews.com/best-practices/stacked-prs/. Last updated: July 24, 2026

Using Copilot for Automated Code Reviews

Fri, 22 Nov 2024 08:59:30 GMT

One of the most intriguing applications of GitHub Copilot is its potential to assist in code reviews.
In this tutorial, we’ll explore how Copilot helps you understand code, suggest improvements, explain code, and answer specific questions about the code under review.

You’ll learn two main ways to use Copilot:

Copilot in the IDE (Visual Studio Code)
Copilot on GitHub for reviewing pull requests (currently in beta).

Along the way, I’ll share my thoughts on the use cases and workflows for AI-assisted code reviews, as well as the weaknesses of this approach.
While GitHub Copilot can transform how we conduct code reviews, we will see that human oversight remains essential throughout the process.

GitHub Copilot

GitHub Copilot is a coding assistant that uses large language models (LLMs) under the hood. GitHub Copilot is a coding assistant powered by large language models (LLMs). It integrates seamlessly with various integrated development environments (IDEs), providing developers with real-time suggestions, code completions, and review functionality.
Recently, Copilot has also become available (in beta) directly on GitHub, where it assists developers in reviewing pull requests (PRs).

Code Under Review

In this tutorial, you’ll explore how to use GitHub Copilot to review code effectively.
Let’s start with a snippet of code from a file named auth.js. Below, you’ll find the first code sample we’ll review.

You don’t need to analyze the code in detail right now, but take a quick look.

Do you notice any opportunities for improvement?

import React, { createContext, useState, useEffect } from "react"
import firebase from "gatsby-plugin-firebase"

export const AuthContext = createContext({})

const AuthProvider = ({ children }) => {
  const [user, setUser] = useState()

  useEffect(() => {
    firebase.auth().onAuthStateChanged(user => setUser(user))
  }, [])

  return (
    <AuthContext.Provider value={{ user, setUser }}>
      {children}
    </AuthContext.Provider>
  )
}

export default AuthProvider

Copilot in the IDE

As mentioned earlier, GitHub Copilot is available in IDEs and on GitHub itself.
We’ll begin by reviewing this piece of code within the IDE and later compare it to the review experience on GitHub in the PR view.

In Visual Studio Code, a small context menu provides access to Copilot’s AI-powered capabilities.
This menu allows you to Explain, Fix, or start a chat (Add File to Chat) about a specific piece of code.
You can also use it to generate documentation or tests with the help of AI.
Recently, Copilot introduced a Review and Comment option for reviewing code directly in the IDE, which is what you’ll use today to get started.

Review and Comment

Previously, the primary option for reviewing code with GitHub Copilot was to start a chat with the LLM. This was particularly useful when you wanted an exploratory and interactive approach to understanding and improving your code.

Now, with the Review and Comment option, you have access to a more direct, guided, and structured way to review your code.
To start a guided review, select the parts of the code you want to examine and ask GitHub Copilot to Review and Comment.

Copilot then opens a review interface that highlights suggested changes line by line within the file under review.
This interface resembles tools commonly used for refactoring or resolving merge conflicts, making it intuitive for developers.

Here’s an example of the interface in action while reviewing the auth.js file in the IDE:

Line by Line Review

The AI suggested code change is embedded directly in the code. Copilot injects the review interface just below line 10, which is the main line of code this code review comment addresses.
The review interface highlights the original lines in red and the suggested changes in green, following a familiar diff-style format.

You can either accept the changes or discard them and move to the next suggestion.
What stands out to me is that Copilot also provides a brief explanation of the reasoning behind each suggestion, making it easier to understand the proposed improvements.

However, one usability issue I’ve encountered is that accepting a change automatically moves you to the next one.
This behavior means you can’t review or verify the outcome of the change Copilot applied.
I’d prefer an option to accept the change and stay on the same line (e.g., line 10) to inspect the result before proceeding.

Overall, the Review and Comment functionality is straightforward and enables a highly structured approach to code review, aligning well with automated code review practices.

Let Copilot Explain Code

Another way Copilot can assist in a review is by explaining the code.
This feature helps you build a mental model of the code changes, improving your ability to provide meaningful feedback during the review process.

To prompt Copilot for an explanation, select the code and right-click to open the context menu. Then, click Explain.
The executed prompt is: “@workspace /explain Write an explanation for the active selection as paragraphs of text.”

This prompt triggers GitHub Copilot to generate a detailed explanation of the selected code, as shown in the screenshot below.
The explanation highlights objects, components, and function calls, making it easier for developers to associate the description with the code itself.
Additionally, functions are clickable, linking you directly to the file where they are defined.

After the explanation, a chat interface appears, allowing you to interact further with the LLM about the code.

This chat interface is also a great starting point when you want a more exploratory experience with the LLM and the code.

Inline Chat with Copilot

Another way to interact with GitHub Copilot in the IDE is by using the inline chat (Editor Inline Chat) interface, which provides explanations directly within the file view.

One challenge with inline prompts is that the chat window is quite small, while the explanations or suggestions are often lengthy.
This results in extensive scrolling, which can feel cumbersome and less user-friendly, as shown in the screenshot below.

Fortunately, you can prompt Copilot to View in Chat, which opens the conversation in a larger, dedicated window (in my case, on the right-hand side).

Asking Copilot for Changes

The inline interface is particularly effective for prompting Copilot to make changes.
For example, you can ask Copilot, “Change this function call to a more secure one.”
It will then present you with suggested changes, though without much explanation by default.

However, the interface initially only displays the newly generated code, not the original code.
This can make it difficult to compare and evaluate whether the suggested change is truly helpful.

To address this, you can enable the Toggle Changes option, which shows a side-by-side comparison of the original and new code—similar to what many developers are accustomed to in code reviews.

If you’re unsure about the suggested changes, you can also ask Copilot to explain its suggestions, adding clarity and helping you assess their value.

Chatting with Copilot About the Code

One of the most common ways LLMs assist developers today is through “traditional” chat interfaces.
In this interface, developers can ask the LLMs questions about the code or explore it interactively.
GitHub Copilot also offers this method of interaction, providing a versatile way to engage with the code.

The inline chat we discussed earlier is another representation of this chat interface.
Similarly, the Explain option brings you directly into this interface with a prefilled standardized prompt, enabling a seamless transition between exploration and explanation.

Copilot to Review PRs on GitHub

The GitHub Copilot experience for pull request reviews is currently similar to the chat functionality in the IDE or tools like ChatGPT on the web.
However, it provides a less directed and structured approach compared to the Explain and Comment interface available for automated code reviews in the IDE.

There are several ways to trigger Copilot directly on GitHub during a PR review. For instance, you can click on a line of code, which opens a small Copilot context menu.
From there, you can select options such as Explain or Attach to current thread to add Copilot’s response to an existing conversation.

AI Code Explanation for Code Review

When you click Explain, it triggers a pop-up window that resembles the familiar chat interface.

Using AI to explain code is an excellent use case during a code review.
It helps the reviewer understand the code more effectively and build a mental model of the changes.
However, this feature does not provide improvement suggestions from Copilot, as shown in the example below.

Generating a PR Summary from Multiple Files

Another way to trigger GitHub Copilot is through the menu located above all the file changes, as shown in the screenshot below. This option allows you to select multiple files from the change set and start a chat with Copilot about them.

One practical use case is to have AI automatically summarize the pull request for us. While there are already tools and plugins available that offer automatic PR summarization, GitHub now provides this functionality out of the box.

To try it out, I selected all source code files changed in this PR, along with relevant configuration files. I omitted content-related files such as markdown files, as well as certain configuration or generated files like package.json.

The auth.js file is part of a rather large PR, as shown below. I ended up adding 14 source code files the context of Copilot.

For the sheer amount of code changes, Copilot’s automated code review summary is surprisingly short and lacks meaningful insights. It primarily lists some of source code files included in the change set, grouping them together logically.

I also asked Copilot to indicate where I should focus my attention during the code review. While it provided an answer, I found it underwhelming. The response listed a few files but offered no explanation for why these files were highlighted. Additionally, the auth.js file—one that I, as a human reviewer, consider highly relevant—was notably absent from the list.

I am disappointed with both responses. Perhaps my prompt wasn’t clear or specific enough. To address this, I tried again with the prompt: “Summarize the PR in more detail.” Copilot processed the request but returned the same short and unhelpful summary as before. Bummer.

Next, I sent another prompt focused on risk assessment: “What are the most risky changes in this PR?” Once again, Copilot took its time to create the plan, but the answer was almost identical to the previous response. Unfortunately, it offered little insight into the PR, and the risk assessment did not seem appropriate or actionable.

Don’t use AI for Risk Assessment

A chat interface is a powerful tool, letting you ask any question or provide any instruction you want to the LLM. While this flexibility is valuable, it doesn’t prevent us from making unwise requests. For example, asking an automated code reviewer to assess the risk of a pull request is one such misstep.

LLMs are fundamentally unsuited for assessing risk in source code. They lack the deep understanding of domain-specific logic, semantic nuances, and file interdependencies required for accurate analysis. Risk often arises from how files interact or their role within the system. These are all factors LLMs are incapable of dynamically evaluating.

LLMs treat all input equally, making it hard for them to prioritize files based on critical factors like functionality, or security and business relevance. Without domain-specific knowledge or explicit input, LLMs cannot evaluate the importance or business-critical nature of a file.

As these models often respond regardless of their suitability for the task, it is crucial to critically evaluate whether this type of AI is appropriate for the specific task at hand.

Asking Copilot for Code Improvements

The experience of interacting with Copilot on files may feel smoother when focusing on a single file. For instance, let’s choose only auth.js. Once selected, the chat window opens, and Copilot is ready to assist by responding to your questions or following your instructions.

Let’s ask Copilot: “How can this code be improved?” and review its response.

When you prompt Copilot, the page reloads. If you were examining a specific change in the long list of PR changes, you’ll find yourself back at the beginning of the list. This behavior can be frustrating and unhelpful, as it causes you to lose the context of the code you just reviewed and sought assistance for.

Another negative UX aspect is that the chat window is small, requiring significant scrolling to read Copilot’s full response. Unlike the IDE experience, there is no option to open the conversation in a larger, more convenient window.

Copilot’s response is detailed and starts with a list of improvement suggestions, including enhancements for error handling, type safety, and dependency management.

When we scroll down, our personal automated code reviewer, Copilot, provides an updated version of the code that you can copy and paste.
However, during a code review, the ability to copy and paste the entire updated code is not particularly useful.

What’s more important is mapping the new code back to the code under review, identifying the specific lines that were changed, and determining where to leave comments.
Since the piece of code under review is relatively small, it’s manageable to map the updated code in the chat window to the corresponding lines in the diff view.

If you find Copilot’s suggestion useful, you can add a comment or make a concrete code change suggestion directly in the PR.
However, for non-trivial changes, I personally feel uneasy making edits this way.

For anything beyond a simple adjustment, I prefer to make the changes within the IDE, where I can immediately verify if I’ve made a mistake (maybe even just a typo, or copy/paste error).
This ensures a smoother and more reliable workflow, particularly for complex updates.

Should We Ask AI to Review a PR?

The idea of a peer reviewing code already submitted as a PR by prompting an LLM to improve it feels rather strange.
Ideally, the process of prompting AI to refine code should be driven by the developer who wrote the code and should occur in the IDE before the PR is submitted for peer review. This use case, or a self-review is nicely covered by Copilot in the IDE.

On the other hand, using AI to explain code during a PR review is a valuable and practical use case.
Similarly, if a reviewer has a suspicion or an improvement suggestion, interacting with the LLM can help clarify their thoughts.

In such scenarios, it’s unlikely that the reviewer would use a prompt as general as the one in this example.
More specific prompts tend to yield better results. A code review checklist can provide inspiration for crafting effective code review prompts.

In most cases, reviewers will have a concrete question or suspicion about the code and will ask the AI code reviewer for targeted feedback directly.

AI Helps Reviewers Verify Their Suggestions

One of the most significant benefits AI offers to code reviewers is helping them build a mental model of the changes by explaining the code and providing feedback on their suggestions.

For example, let’s imagine we’re reviewing the code and notice:

const [user, setUser] = useState().

We think it might be better to change this to:

const [user, setUser] = useState(null).

Yet, feel uncertain and insecure about making the suggestion. What if we are wrong? Insecurity during code reviews, and even anxiety, is a common challenge. This is where AI can help us investigate our idea.

Let’s ask Copilot if our suggestion makes sense and why.

Copilot provides a detailed explanation with three reasons why initializing useState() with null is a better approach. We can take it a step further and ask our AI code review helper to summarize this explanation, making it easier to use as a concise review comment.

AI Trustworthiness Is a Problem

One of the biggest challenges with using LLMs for code reviews is the trustworthiness of their suggestions. Although it might seem like AI understands or is intelligent, this is not the case.

The code suggestions provided by Copilot, or any other automated code review tool that uses LLMs, rely purely on statistical relationships. The LLMs are designed to predict the next most likely token, resulting in outputs that appear plausible.
However, even though the output may seem correct, it can sometimes be entirely wrong.

I’ve personally observed AI fabricating API calls that don’t exist, suggesting catching exceptions from libraries not in use, and don’t get me started on the suggestions I received for improving CSS code. Even while working on this tutorial, there were moments when Copilot generated incorrect or incomplete code, as shown in the appendix.

While some of the AI-generated code is correct, the potential for errors is too significant to ignore, especially during a code review. A code review is not the right place to take chances with unverified suggestions. This is why it’s critical to thoroughly evaluate any AI-generated code review feedback before acting on it.

Evaluating AI Code Review Suggestions

An LLM can be a valuable companion during a code review, especially when you need it to remind you of best practices or highlight potential issues in the code. However, it’s crucial that you have the competency to evaluate the proposed changes critically (and quickly).

For developers who are less familiar with a framework or programming language, relying on AI for code reviews can be tempting. Yet, the less skilled you are at writing or improving the code yourself, the harder it becomes to assess the validity of the AI’s code review suggestions.

Research indicates that even experienced developers struggle to fully understand, modify, or debug code generated by LLMs.
As a result, evaluating AI-generated code review suggestions—some of which can be entirely wrong—remains a challenging task.

Evaluating Our AI Code Review Suggestion

Let’s examine Copilot’s recommendation to modify the line of code where we call onAuthStateChanged. Our automated code reviewer suggested using a pattern to ensure that any subscriptions or side effects are properly cleaned up when a component is unmounted or before the effect is re-executed. However, if we’re not familiar with React or the Firebase API, it can be difficult to determine whether this pattern is applicable in this context.

If we refer to the official Firebase documentation, we notice that the code snippets provided there do not use this pattern. This omission could also explain why it’s not present in the existing codebase.

After reviewing the proposed solution, the reviewer might feel even more uncertain:

Is this a valid pattern?
Should it be applied in our case?
Why wasn’t it included in the official documentation?

If the reviewer is unsure about the AI-generated suggestion, there are three possible approaches:

Trust the AI and recommend the change anyway.
Stay cautious and decide against recommending the change.
Dig deeper by conducting further research to arrive at a conclusion.

Option one is not recommended, as it assumes AI is infallible. Option two is a safe choice but may overlook opportunities for improvement. Option three can lead to valuable learning and potentially improve the codebase quality, though it requires more time and effort.

In our case, we chose the third option and found additional documentation on a Firebase-related website. This resource indicates that a listener is returned and can, or should, be used for unmounting.

Does this evidence provide enough justification to propose the change?

Or should we involve a human/colleague to review the AI-based code suggestion?

😜

AI Code Review Belongs in the IDE

When an automated code review is conducted in the IDE, the process of iteratively evaluating AI suggestions becomes a natural part of the development workflow. AI-assisted code reviews are an excellent tool for self-review, allowing developers to inspect and improve their own code before involving others. There’s no need to include a peer in this semi-automated code review process—unless during an AI pair programming session.

In the IDE, developers can thoroughly modify, enhance, and test the AI code review suggestions. Yet, by the time the code reaches the code review stage, the developer should have already leveraged AI to assess and refine their solution.

Once a code review begins, the stakes for changing the code based on AI suggestions increase significantly, while the reviewer’s ability to evaluate the suggestion diminishes.

AI Code Reviews Can Be Time-Consuming

While Copilot produced straightforward and sensible suggestions for our code in this tutorial, this is not always the case. Using AI for code reviews can lead to incorrect suggestions, as discussed before, but also to many recommendations that are irrelevant or don’t apply in the given context.

This challenge is similar to the struggle developers face when using static analysis tools for automated code reviews. These tools often generate numerous false positives, which means they are reporting issues that aren’t actual problems.
In contrast, LLMs add another layer of complexity because they are non-deterministic, meaning they can produce different outputs for the same input.

Sifting through irrelevant or inconsistent suggestions is a time-consuming task, making it essential to critically evaluate the AI’s output during a code review, but also to question it’s usefulness and efficiency.

Conclusion: AI Code Reviews Need Human Supervision

Despite advancements in AI, the human element remains irreplaceable in code reviews. There is no such thing as a fully automated code review yet.

AI-generated suggestions can sometimes be terribly incorrect, making code reviews the wrong place to take these risks.
While tools like Copilot are excellent companions in the IDE, they are still assisting technologies rather than autonomous code reviewers.

That said, don’t underestimate the power of AI assistance. An AI reviewer can help developers focus on details, detect errors, improve code quality, handle repetitive tasks, and help them build a mental model of the code.

By combining human expertise with AI capabilities, we can create a balanced approach that leverages the strengths of both.
As AI continues to evolve, its role in code reviews will likely expand, but the need for human oversight will remain critical for a long time.

What’s your experience with AI code reviews? Let me know in the comment section on LinkedIn!

Appendix: Code Generated by Copilot on GitHub

Here’s the complete, improved code snippet that Copilot suggested during our automated code review session.

What do you think?

AI Improved Code

import React, { createContext, useState, useEffect } from "react";
import firebase from "gatsby-plugin-firebase";
import PropTypes from "prop-types";

export const AuthContext = createContext({});

const AuthProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const unsubscribe = firebase.auth().onAuthStateChanged(
      (user) => setUser(user),
      (error) => console.error("Auth state change error:", error)
    );
    return () => unsubscribe();
  }, []);

  return (
    <AuthContext.Provider value={{ user, setUser }}>
      {children}
    </AuthContext.Provider>
  );
};

AuthProvider.propTypes = {
  children: PropTypes.node.isRequired,
};

export default AuthProvider;

Code Explanation from Copilot

The code snippet is a React useEffect hook that listens for changes in the authentication state using Firebase. Here’s a step-by-step explanation:

useEffect Hook: This hook runs a piece of code after the component renders. The empty dependency array [] means it runs only once when the component mounts.
firebase.auth().onAuthStateChanged: This is a Firebase method that sets up an observer on the Auth object to listen for changes in the user’s sign-in state.
Callback Function: The callback function user => setUser(user) is called whenever the authentication state changes. It updates the state with the current user object.
Cleanup Function: The return () => unsubscribe() part ensures that the observer is unsubscribed when the component unmounts, preventing memory leaks.

Copilot's Incorrect Code Suggestions

Below is an “improved version of the code”, as Copilot calls it.

Can you spot the issue with the proposed code?

import { useEffect } from 'react';
import firebase from 'firebase/app';
import 'firebase/auth';

const useAuth = (setUser) => {
  useEffect(() => {
    const unsubscribe = firebase.auth().onAuthStateChanged(
      user => setUser(user),
      error => console.error('Auth state change error:', error)
    );
    return () => unsubscribe();
  }, [setUser]);
};

export default useAuth;

Official source for “Using Copilot for Automated Code Reviews”: https://www.awesomecodereviews.com/automation/copilot-review/. Last updated: November 22, 2024

Best AI Code Review Tools 2026

Thu, 09 May 2024 08:59:30 GMT

Let’s look at the best AI code review tools of 2026. AI-powered code review tools have emerged as valuable allies to developers. AI code reviewers offer automated assistance to streamline the review process, enhance code quality, and reduce the burden on human reviewers.

When I first wrote this article in 2024, seven up-and-coming tools felt like a useful overview. In 2026, new AI code reviewers seem to appear every week. I see this both in my research and in my work with clients. One reason is that AI coding agents produce more code, making review the next obvious bottleneck. Another is that it has become relatively easy to put a pull-request integration around a large language model. The difficult part is not producing review comments; it is producing high-signal comments that understand the codebase, respect team conventions, and do not exhaust developers with false positives.

This article provides an overview of 15 relevant AI code review tools. It is a snapshot rather than an exhaustive directory, and the numbering is not a ranking. I also show how to use a general-purpose LLM as a code reviewer, including when independent or multi-model review passes can help, and examine the pros and cons of using such tools. Finally, I offer best practices for integrating AI reviews into your development workflow.

Here is an outline of what you can expect:

15 Best AI Code Review Tools
Using General-Purpose LLMs for Code Review
- Should You Use a Different Model—or Several?
Pros and Cons of Using AI Code Reviewers
Best Practices for Using AI Code Reviews
Summary

15 Best AI Code Review Tools

In this article, we are not focusing on the best code review tools per se, nor will I highlight the best static and dynamic code review tools. Instead, we are in particular looking at tools that use large language models and agentic workflows to help developers understand and review code changes.

I made the selection based on the features the tools offer, their relevance in 2026, and the range of workflows they cover, not just their popularity. Some are dedicated AI reviewers, some are review features inside a larger developer platform, and one focuses more narrowly on explaining changes. I have removed inactive products from the main list.

AI Code Review Tools at a Glance

This table is a quick orientation, not a substitute for testing a tool on your own pull requests. Platform support, deployment options, and product packaging change quickly, so check the linked tool section before making a final choice.

Tool	Workflow and platforms	Deployment	Best fit
GitHub Copilot	GitHub pull requests and IDE	Hosted	Teams wanting review built into GitHub
Bito	GitHub, GitLab, and Bitbucket pull or merge requests	Hosted	Combining AI review with static and security signals
CodeRabbit	GitHub, GitLab, Bitbucket, Azure DevOps, IDE, and CLI	Hosted	Broad platform coverage and interactive reviews
Qodo	GitHub, GitLab, Bitbucket, and Azure DevOps	Hosted or enterprise deployment	Multi-agent reviews and organization-wide rules
PR-Agent	Major Git platforms, GitHub Actions, and CLI	Open source and self-hosted	Teams wanting model and deployment control
What The Diff	GitHub and GitLab pull requests	Hosted	PR descriptions and stakeholder communication
Cursor Bugbot	GitHub pull requests and Cursor	Hosted	Teams already developing with Cursor
Greptile	GitHub, GitLab, CLI, and coding-agent handoff	Hosted or self-hosted	Repository-wide context and agentic fixes
Graphite Agent	GitHub and Graphite	Hosted	GitHub teams using Graphite’s review workflow
GitLab Duo	GitLab merge requests	GitLab.com or self-managed	Teams committed to the GitLab platform
Amazon Q Developer	IDE, project, and preview GitHub reviews	Hosted	AWS-oriented security and quality review
CodeAnt AI	GitHub, GitLab, Bitbucket, and Azure DevOps	Hosted	AI review combined with quality and security gates
Sourcery	GitHub, GitLab, and IDE	Hosted or self-hosted	Review guides, diagrams, and custom standards
Korbit	Pull-request reviews and team reports	Hosted	Interactive feedback and engineering insights
Kodus Kody	GitHub, GitLab, Bitbucket, and CLI	Open source and self-hosted	Model choice, transparency, and bring-your-own-key

So, let’s have a look at each one of them:

1. GitHub Copilot

GitHub Copilot code review has changed substantially since the original 2024 version of this article. Copilot can now review code in an IDE and act as a reviewer directly inside a GitHub pull request. You can request a review manually or configure automatic reviews for a repository or organization.

Copilot leaves comments and suggested changes, but it does not approve a pull request or request changes. Its review therefore does not satisfy a required human approval or block a merge.

Features:

Native Pull Request Reviews: Add Copilot as a reviewer on GitHub or trigger it automatically with a ruleset.
Suggested Changes: Produces a summary and comments with changes that can be applied from the pull request.
IDE Reviews: Reviews selected code or local changes before they become a pull request.
Custom Instructions: Can use repository-specific instructions to better match a team’s standards.

2. Bito AI Code Review Agent

Bito AI Code Review Agent offers automated, context-aware reviews for pull and merge requests. It looks for bugs, code smells, and security vulnerabilities, and posts recommendations as comments in the existing review interface.

Features:

AI and Static Analysis: Combines LLM-generated feedback with static analysis and open-source vulnerability checks.
Detailed Review Comments: Explains issues and proposes fixes on the relevant lines.
Security Signals: Can include high-severity findings from third-party tools such as Snyk.
Integration: Supports GitHub, GitLab, and Bitbucket, including self-managed GitHub and GitLab.

3. CodeRabbit

CodeRabbit has grown from a GitHub review bot into a broader code review platform. It provides context-aware pull-request feedback, severity levels, summaries, and a conversational interface for asking follow-up questions. Reviews are also available before a pull request through its IDE extensions and command-line tool.

Features:

Context-Aware Reviews: Uses codebase and linked issue context, not only the changed lines.
Interactive Feedback: Lets developers discuss findings and request changes in the review.
One-Click Fixes: Turns suitable findings into directly applicable suggestions.
Broad Integration: Supports GitHub, GitLab, Azure DevOps, and Bitbucket, plus IDE and CLI workflows.

4. Qodo

CodiumAI is now Qodo. Its original PR-Agent evolved into a hosted code review platform, and Qodo 2.0 introduced a multi-agent review architecture in 2026. It uses repository context, pull-request history, and organization-specific rules to prioritize bugs and rule violations.

Features:

Multi-Agent Review: Specialized agents inspect a pull request from different perspectives.
Rule System: Applies team standards learned from the codebase, review history, and explicitly defined requirements.
Prioritized Findings: Focuses on material issues and provides remediation guidance rather than a long list of generic comments.
Integration: Supports GitHub, GitLab, Bitbucket, and Azure DevOps, with deployment options for enterprises.

5. PR-Agent

The earlier version of this article grouped several small ChatGPT-based GitHub Actions together. A more useful 2026 option is PR-Agent, the open-source project that originally came from CodiumAI/Qodo and is now community maintained. It is separate from Qodo’s hosted product and is a good fit for teams that want to control the model, deployment, and configuration themselves.

Features:

Open Source: Apache-2.0 licensed and deployable as a GitHub Action, CLI, webhook, or container.
Review Workflow: Offers commands for reviewing, describing, improving, and asking questions about a pull request.
Model Choice: Can be configured with different commercial or local model providers.
Broad Git Support: Supports GitHub, GitLab, Bitbucket, Azure DevOps, CodeCommit, Gitea, and local repositories.

6. What The Diff

What The Diff remains the narrowest tool in this list. It primarily makes pull requests easier to understand by writing descriptions and summaries for developers and non-technical stakeholders. It now also offers changelogs, weekly progress reports, and AI-assisted refactoring of minor issues.

I would choose it for communication and change documentation, not as the main tool for finding subtle defects.

Features:

AI Descriptions: Creates plain-language descriptions of pull-request changes.
Stakeholder Summaries: Produces translated notifications, weekly reports, and public changelogs.
Inline Refactoring: Helps address smaller issues during a review.
Integration: Works with GitHub and GitLab pull-request data.

7. Cursor Bugbot

Cursor Bugbot brings Cursor into the pull-request workflow. It reviews GitHub pull requests for bugs, security issues, and code-quality problems, then links findings back to Cursor or Cursor’s web agents for fixing.

Features:

Automatic or Manual Reviews: Runs on pull-request updates or in response to a review command.
Repository Rules: Reads .cursor/BUGBOT.md files for project- and directory-specific guidance.
Connected Fixes: Opens findings with their context in Cursor and supports automated fixes.
Integration: Currently centered on GitHub and the Cursor development environment.

8. Greptile

Greptile indexes a repository as a graph before reviewing changes. This lets it reason about dependencies beyond the pull-request diff and is one of the clearest examples of the 2026 move toward codebase-aware, agentic review.

Features:

Repository Graph: Uses functions, classes, and dependencies from the wider codebase as review context.
Adaptive Reviews: Learns from reactions, replies, previous review comments, and custom rules.
Fix with Your Agent: Sends a finding and its context to tools such as Claude Code, Codex, Cursor, or Devin.
Integration and Deployment: Supports GitHub and GitLab, with cloud, self-hosted, and air-gapped options.

9. Graphite Agent

Graphite Agent is the AI reviewer inside Graphite’s GitHub-compatible code review platform. It automatically comments on pull requests, proposes fixes, and focuses on logic bugs, edge cases, security, and performance issues.

Features:

Codebase-Aware Review: Uses repository context to evaluate pull-request changes.
Custom Rules and Exclusions: Enforces team standards while suppressing known sources of noise.
Review Analytics: Tracks findings, accepted suggestions, acceptance rates, and developer feedback.
GitHub Workflow: Comments and suggested fixes appear in both Graphite and GitHub.

10. GitLab Duo Code Review

GitLab Duo code review is the most natural option for teams already working in GitLab. You assign @GitLabDuo as a reviewer. Depending on the plan and group configuration, GitLab runs either its agentic Code Review Flow or the more diff-focused GitLab Duo Code Review.

Features:

Native Merge-Request Review: Review feedback stays inside the existing GitLab workflow.
Agentic Option: Code Review Flow can inspect repository structure and cross-file dependencies through multi-step reasoning.
Custom Instructions and Automation: Teams can configure guidance and automatic reviews.
Follow-Through: GitLab Duo can help resolve review discussions by changing, committing, and pushing code.

11. Amazon Q Developer

Amazon Q Developer combines generative AI with rule-based security and quality detectors. It can review local changes, a file, or an entire project in supported IDEs. Its automated reviews inside GitHub are also noteworthy, although that integration is still marked as preview.

Features:

Broad Security Review: Covers SAST findings, secrets, infrastructure as code, dependencies, and code quality.
IDE and Project Reviews: Reviews a diff, file, workspace, or repository and can propose in-place fixes.
GitHub Pull Requests: In preview, automatically reviews new pull requests and posts threaded findings and suggested fixes.
Project Rules: Reads team standards from Markdown files in .amazonq/rules.

12. CodeAnt AI

CodeAnt AI combines AI pull-request review with a broader code-quality and security platform. It reviews changes for bugs, vulnerabilities, quality problems, and architectural concerns, then posts actionable findings directly on the pull request.

Features:

Specialized Review Agents: Covers code quality, security, dependencies, secrets, and infrastructure configuration.
Quality Gates: Can use findings to prevent risky changes from being merged.
Interactive Findings: Supports re-reviews, questions, validation, and suggested fixes.
Broad SCM Support: Works across GitHub, GitLab, Bitbucket, and Azure DevOps workflows.

13. Sourcery

Sourcery provides automated reviews in pull requests and IDEs. In addition to line-level findings, it creates a summary and a review guide with diagrams, which can help human reviewers understand larger changes.

Features:

Broad Review Coverage: Looks for bug risks, design issues, code quality, performance, and team-standard violations.
Reviewer Aids: Produces change summaries, inline suggestions, review guides, and diagrams.
Customizable Feedback: Learns from reactions and can enforce a team’s own coding standards.
Integration: Supports GitHub, GitLab, popular IDEs, and self-hosted enterprise deployments.

14. Korbit

Korbit positions itself as an interactive AI reviewer that gives feedback before the human team starts its review. It focuses on higher-impact findings, explains why they matter, and can respond to questions inside the pull-request discussion.

Features:

Contextual Reviews: Uses project context, team feedback, and custom settings to tune findings.
Interactive Fixes: Answers follow-up questions and can provide replacement code in the pull request.
PR Descriptions and Summaries: Generates handoff context in addition to review findings.
Team Insights: Extends review data into release notes, sprint summaries, and engineering reports.

15. Kodus Kody

Kodus Kody is an open-source, model-agnostic AI code reviewer. It stands out for teams that want transparency into which files and context the reviewer used and prefer to pay their model provider directly.

Features:

Open Source and Model Agnostic: Supports different AI providers and a bring-your-own-key approach.
Repository-Wide Context: Uses semantic analysis and code search across the repository.
Team Rules and Learning: Enforces custom standards and adapts to developer feedback.
Integration: Works directly with GitHub, GitLab, and Bitbucket.

Using General-Purpose LLMs for Code Review

You do not necessarily need a dedicated AI code review tool. A general-purpose LLM can review a pasted code snippet, a pull-request diff, or—if it has access to your repository—the complete change and its surrounding code. Many of the products above package this basic capability with repository access, automatic triggers, persistent rules, inline comments, and reporting.

Before pasting proprietary code into a chat interface, confirm that the provider and account are approved for that code, and check the provider’s retention and model-training policies.

The simplest possible prompt is:

Review this code.

This can be useful for a quick second look, but a more focused prompt usually produces more relevant feedback:

Review this change for security issues. Focus on authentication, authorization, input validation, injection risks, secrets, sensitive-data exposure, and unsafe dependencies. For every finding, cite the relevant code, explain the impact, and suggest a fix. Do not invent a finding when the evidence is weak.

You can change the review perspective to match the risk of the change:

Review this frontend change for usability and accessibility. Check keyboard navigation, focus management, semantic HTML, labels and accessible names, color contrast, error messages, loading states, and screen-reader behavior. Separate blocking issues from optional improvements.

For a deeper review, give the model the intended behavior rather than only the code:

Review this pull-request diff against the requirements and repository conventions below. Look for functional bugs, missing edge cases, regressions, security and privacy risks, performance problems, and missing tests. Return only actionable findings. For each one, include severity, file and line, evidence, impact, and a proposed fix. If you need context that is not available, ask for it instead of guessing.

Context matters more than a clever reviewer persona. Give the model the requirement or issue, the diff, relevant surrounding code, repository conventions, and test results when possible. In an evaluation of general-purpose LLMs as code reviewers, review performance declined when the models did not receive the problem description. Even with good context, the researchers concluded that human review remains necessary because LLMs also produce faulty assessments and fixes.

Should You Use a Different Model—or Several?

There is anecdotal evidence from practitioners, and I see this in some client workflows as well, that the model that wrote the code is not always the best model to review it. A different model may question different assumptions and notice a problem that the generating model repeats or overlooks. Research on LLMs used as judges has also found self-preference bias, although that research is broader than code review and does not prove that a different model will always review code better.

The more defensible lesson is to seek independent review passes. The 2026 SWR-Bench study found that aggregating several independent review reports—using different models or multiple runs of the same model—improved code-review F1 scores by up to 43.67%. The gains came mainly from finding more real issues; false positives remained an important limitation.

This explains why some companies run several AI reviewers on the same change, as long as they can afford the model tokens and the human attention needed to triage the results. I would use this selectively rather than adding several bots to every pull request:

Let one model or coding agent implement the change.
Give a different model a read-only review with the requirement, diff, relevant code, and test evidence.
For higher-risk changes, run separate focused passes for correctness, security and privacy, and—for user-facing changes—usability and accessibility.
Deduplicate the findings and require evidence for each one.
Let a human decide which findings are valid before applying changes.

More AI reviewers create more coverage, but also more cost and review noise. Agreement between several models is useful evidence, not proof of correctness. Tests, static analysis, and accountable human review still provide different and necessary layers of assurance.

Pros and Cons of Using AI Code Reviewers

AI code reviewers offer significant advantages, including fast first feedback and the ability to detect issues that a busy human reviewer might miss. They can apply configured standards consistently across many pull requests. However, they also have limitations, including false positives, incomplete domain knowledge, and no accountability for the final decision. Balancing AI and human reviews can help mitigate these drawbacks.

Pros:

Time Savings: AI code reviewers significantly reduce the time required for code reviews by automating the identification of bugs, code smells, and security vulnerabilities. This allows developers to focus on more complex tasks and reduces the overall time spent in the review process.
Consistency: AI tools can apply the same configured standards across all code reviews without getting tired. This is useful for checking recurring team conventions.
Additional Detection: AI reviewers provide another pass over the change and can identify bugs, duplications, missing edge cases, and potential security threats that a human reviewer might overlook.

Cons:

Lack of Knowledge Sharing: One significant drawback of AI code reviews is the lack of human interaction, which is essential for knowledge sharing and mentoring among developers. Code reviews conducted by humans often serve as learning opportunities where experienced developers can share insights and best practices with junior team members.
Limited Contextual Understanding: AI tools may lack the domain-specific and business context necessary to provide meaningful feedback. They might struggle to understand the broader implications of code changes within the specific context of a project or organization, leading to potentially less relevant or accurate suggestions.
Wrong Suggestions and Review Noise: AI suggestions can be incorrect, insecure, or harmful. A tool that produces too many low-value comments can also train developers to ignore all of its feedback.
Privacy and Governance Questions: A reviewer needs access to source code and sometimes issue, repository, or organizational context. Teams should understand what is sent to model providers, how long data is retained, and which deployment options are available.

Best Practices for Using AI Code Reviews

To maximize the benefits of AI code reviewers, it is essential to combine them with human expertise. It’s also a best practice to combine AI code reviewers that are based on large language models, with rule-based static and dynamic analysis tools. Use AI for initial reviews to catch obvious issues, followed by human reviews for contextual insights and mentoring. Customizing AI tools to align with your project’s standards, using AI feedback as a learning tool, and continuously evaluating the quality of its comments can further enhance their effectiveness.

By integrating AI code review tools thoughtfully, development teams can achieve a harmonious balance that leverages the strengths of both automated and human reviews, leading to more robust and efficient code development processes.

Combine AI and Human Reviews: Use AI code reviewers to handle the initial pass, identifying obvious issues and potential vulnerabilities. Follow up with human reviews to ensure contextual relevance and facilitate knowledge sharing among team members.
Combine with rule-based code review automation tools: Make sure to integrate static and dynamic analysis checkers within your development lifecycle. You can use them either as pre-commit or post-commit hooks, and many automated code review tools even leave comments on your reviews.
Customize AI Tools: Configure AI code review tools (if possible) to align with your project’s coding standards and practices. This can help improve the relevance and accuracy of the feedback provided by the AI.
Require Developers to Evaluate Suggestions: Developers should understand an issue and its proposed fix before applying it. Do not turn a plausible-looking AI comment into an automatic change.
Monitor Signal, Not Comment Volume: Pilot a tool on a few repositories and track accepted, dismissed, and incorrect findings. Tune its rules and sensitivity based on that feedback.
Review Data Handling: Check code retention, model-training policies, subprocessors, access permissions, and self-hosting options before connecting sensitive repositories.
Use Multiple Review Passes Selectively: For high-risk changes, consider independent, focused reviews with a second model or tool. Deduplicate the results and keep a human responsible for deciding which findings are valid.

Summary

By integrating some of the world’s best AI code reviewers effectively within the development workflow, teams can achieve a balance that maximizes the strengths of both automated and human reviews, leading to higher quality and more secure code. New AI code review tools are still popping up at a remarkable pace. While it is useful and often fun to evaluate them, the number of comments a tool can generate is not a measure of review quality. The important questions are whether it finds material issues, fits the team’s workflow, protects the code, and helps rather than distracts human reviewers.

AI is not foolproof, and we must be careful that it does not introduce problems and errors into our code. If you want to learn more about automation during code reviews, check out my article on static and dynamic code review tools, as well as the best code review tools.

Official source for “Best AI Code Review Tools 2026”: https://www.awesomecodereviews.com/tools/ai-code-review-tools/. Last updated: July 24, 2026

13 Best Automated Code Review Tools for Static Analysis and Security (2026)

Thu, 09 May 2024 08:59:30 GMT

Automated code review tools can find quality problems, security vulnerabilities, and policy violations before a change reaches a human reviewer. Used well, they reduce repetitive review work and help teams find certain issues faster and more consistently. Automating mechanical checks is also a code review best practice.

Scope: This comparison focuses on static analysis, security scanning, and quality gates that run locally, in CI, or on pull requests. If you want tools whose primary reviewer is a large language model, see the separate comparison of AI-based code review tools.

Last verified: July 23, 2026. I selected tools that are actively maintained and useful during code review, considering pull-request integration, language coverage, configurable quality gates, deployment options, and whether developers can act on the findings.

This article covers:

Code Analysis Platforms
- Codacy
- DeepSource
- SonarQube
- Qlty
- Qodana
- Semgrep
- Datadog Code Security
Static analysis and linting tools
Security-focused automated code review tools
- Snyk
- CodeQL
- Checkmarx
- CodeSonar
- Coverity
- SpotBugs

Automated Code Review Tools

The products below do not replace human review. They complement manual code review tools by checking changes consistently and reporting findings where developers already work. Some now use AI to explain or fix findings, but their core value still comes from repeatable analysis, repository policies, and quality gates.

Tool	Best for	Primary analysis	PR feedback or gates	Free option
Codacy	Multi-language quality governance	Quality, security, duplication, coverage	Yes	Free open-source plan
DeepSource	Automated remediation across common stacks	Quality, SAST, SCA, secrets, IaC	Yes	Free individual and open-source plans
SonarQube	Organization-wide “clean as you code” policies	Quality, reliability, security, coverage	Yes	Free Community Build
Qlty	GitHub-centric linting and coverage	Linting, coverage, maintainability, security	Yes	Free cloud tier and CLI
Qodana	Teams already using JetBrains inspections	Quality, licenses, dependencies, coverage	Yes	Free Community license
Semgrep	Custom security and engineering policies	SAST, SCA, secrets, custom rules	Yes	Open-source CLI
Datadog Code Security	Connecting code findings with runtime context	SAST, SCA, IAST, secrets, IaC	Yes	Commercial trial
Snyk	Developer-first application security	SAST, SCA, containers, IaC	Yes	Free and paid plans
CodeQL	Deep, queryable security analysis on GitHub	Semantic SAST	Yes	Free for public repositories
Checkmarx	Enterprise application-security programs	SAST, SCA, IaC, API, containers	Yes	Commercial
CodeSonar	Safety-critical and embedded software	Whole-program and binary analysis	Yes	Commercial trial
Coverity	Large, complex, or compliance-heavy codebases	Deep static analysis	Yes	Free service for registered open-source projects
SpotBugs	Lightweight Java bug detection	Java bytecode analysis	Via CI integrations	Open source

Code Analysis Platforms

Code analysis platforms combine multiple analyzers with repository-wide configuration, dashboards, pull-request feedback, and quality gates. They are especially useful when a team needs consistent rules across several repositories or programming languages. The difficult part is rarely turning on more rules; it is configuring useful checks without overwhelming developers with noise.

Codacy

Codacy combines static analysis with security findings, duplication and complexity metrics, and code coverage. Teams can choose the underlying tools and rules, define organization-wide coding standards, and use quality gates to prevent new problems from being merged.

Its current GitHub integration reports quality, security, and coverage information directly in pull requests. Codacy can also provide generated patches for supported findings, while its AI Reviewer adds a contextual review that uses source code and pull-request metadata. These features mean the older description of Codacy as a tool that only lists issues is no longer accurate. Codacy is a good fit for teams that want one configurable view across several languages and repositories. See the current Codacy pull-request documentation.

DeepSource

DeepSource analyzes pull requests and commits for code-health issues, security vulnerabilities, secrets, infrastructure-as-code problems, dependency risks, and coverage. Its detailed issue descriptions make findings useful for learning as well as enforcement.

DeepSource’s Autofix remediation engine can propose changes, create a pull request from a default-branch analysis, or commit an accepted fix to an existing pull-request branch. AI Review and AI-assisted Autofix are available alongside deterministic analyzers. Review all generated changes and run your tests before accepting them; automated remediation should shorten feedback loops, not bypass engineering judgment. The DeepSource product overview and Autofix documentation describe the current workflow.

SonarQube

SonarQube covers maintainability, reliability, duplication, coverage, and security. The product family includes IDE analysis, SonarQube Cloud, and self-managed SonarQube Server, with a free Community Build available for smaller needs.

Its strongest code-review feature is the focus on new code: teams can apply a quality gate only to the changes introduced by a pull request instead of blocking developers on an entire legacy backlog. Results can decorate pull requests and prevent merging when a gate fails. Sonar Quick Fixes can edit supported findings, and paid editions offer AI CodeFix for eligible issues. Careful rule and baseline configuration is still essential so that the tool reduces technical debt without creating alert fatigue.

Qlty

Qlty is the successor to Code Climate Quality. Existing Code Climate customers were migrated to Qlty, and the old Code Climate API was disabled in July 2025. Qlty keeps the earlier product’s focus on maintainability and code coverage while adding faster local analysis, more plugins, security scanning, quality gates, and AI-assisted fixes. See the official Code Climate migration overview.

Qlty is particularly relevant for GitHub teams that want linting, auto-formatting, duplication, complexity, coverage, and changed-code gates in one pull-request workflow. Its free CLI also lets developers reproduce many checks locally before pushing. Teams moving from Code Climate should expect to review their configuration and coverage uploader rather than treating Qlty as a drop-in rename.

Qodana

Qodana brings JetBrains’ IDE inspections into CI and pull requests. It supports more than 60 languages and technologies, can establish a baseline for existing issues, and can fail a pipeline when new findings exceed a configured severity threshold.

Qodana is a natural choice for teams already relying on IntelliJ-based IDEs because local inspections and CI checks can use the same analysis engine. Reports can also be viewed in JetBrains IDEs or Visual Studio Code. For supported issues, Quick-Fixes can be applied through a generated pull request rather than by editing code blindly. The Qodana documentation describes its free Community license and paid team features.

Semgrep

Semgrep is a fast, pattern-based analysis tool with products for static application security testing, software composition analysis, and secrets detection. Its open-source CLI is useful on a developer machine or in CI, while the platform adds centralized policies, triage, and pull-request integration.

Semgrep is especially useful when a team wants to encode organization-specific review guidance. A short custom rule can flag a dangerous API, an insecure framework pattern, or a convention that reviewers otherwise repeat manually. Findings can appear as pull-request comments or block a merge in CI. Start with a small, high-confidence ruleset: custom rules are powerful, but a noisy policy will be ignored. Semgrep’s documentation includes examples for automating recurring code-review comments.

Datadog Code Security

Datadog Code Security combines static code analysis, software composition analysis, runtime code analysis, secrets scanning, and infrastructure-as-code security. Diff-aware comments can report new findings directly on GitHub, GitLab, or Azure DevOps pull requests, while PR gates can enforce severity thresholds. The differentiator is runtime context: teams already using Datadog can connect repository findings with services running in production and prioritize vulnerabilities that affect deployed code. See Datadog’s current pull-request comment documentation.

Static analysis and linting tools

You may not need a platform if one or two language-specific tools cover your stack. For JavaScript and TypeScript, common choices include ESLint and Biome. Python teams can use Ruff or Pylint, while Ruby teams often use RuboCop. Java projects can add PMD or SpotBugs, and C/C++ projects can use clang-tidy.

Keep analysis and formatting conceptually separate. Tools such as Black and Prettier primarily format code; linters and static analyzers look for bugs, risky patterns, or policy violations. Many tools do both, but the distinction helps teams decide which checks may safely auto-fix code and which deserve human review. Run fast, deterministic checks locally or in a pre-commit hook, then repeat the important gates in CI.

Security-focused automated code review tools

Snyk

Snyk is a developer-focused application-security platform. Snyk Open Source finds vulnerable dependencies and license risks, while Snyk Code analyzes first-party source code. Snyk Container and Snyk Infrastructure as Code extend that coverage to images, Kubernetes, Terraform, and other deployment definitions.

Developers can run Snyk locally, in an IDE, in CI/CD, or through a source-control integration. Pull-request checks can prevent a newly introduced vulnerability or policy violation from being merged, and supported findings include remediation guidance. This broader product scope replaces the older characterization of Snyk as only a dependency checker. The Snyk scanning overview explains the current products and scanning methods.

CodeQL

CodeQL is a powerful static analysis tool developed by GitHub that can be used to find security vulnerabilities and bugs in code. It works by analyzing the source code of a program and building a database of information about how the code works.

CodeQL is designed to be highly flexible, allowing developers to create their own queries to search for specific types of issues in their code. It can be used to find a wide range of issues, including buffer overflows, injection vulnerabilities, and other security vulnerabilities. GitHub code scanning can run standard or custom CodeQL queries on pull requests and report findings before merge. CodeQL is free for public repositories; private repository use is part of GitHub’s paid security offering.

Checkmarx

Checkmarx One is a commercial application-security platform covering SAST, software composition analysis, infrastructure as code, API security, containers, and software-supply-chain risks. Its static analysis uses data-flow techniques to detect issues such as injection vulnerabilities, cross-site scripting, and unsafe memory handling across a broad set of languages.

Checkmarx now integrates directly with the code-review lifecycle. It supports GitHub, GitLab, Azure DevOps, and Bitbucket repository integrations; opening or updating a pull request can trigger a scan and add a PR decoration summarizing new issues, fixed issues, and policy violations. Developers follow links to the full findings and remediation guidance in Checkmarx One. See the current repository integration documentation.

CodeSonar

CodeSonar is a commercial static analysis product from AdaCore. CodeSecure merged with AdaCore in 2025, so older CodeSecure product links and ownership references are no longer current.

CodeSonar performs deep, whole-program analysis of source code and binaries. It focuses on difficult defects such as buffer overflows, null-pointer dereferences, use-after-free errors, tainted data flows, and concurrency problems. In addition to C and C++, it supports languages including Java, C#, Go, Python, JavaScript, TypeScript, Kotlin, and Rust. Its strongest fit is enterprise, embedded, safety-critical, and high-integrity software where teams need standards such as MISRA, CERT, ISO 26262, or DO-178C and can justify a heavier analysis setup.

Coverity

Coverity Static Analysis is an enterprise-grade product from Black Duck. It builds a structural model of a codebase to identify security and quality defects across files, functions, and execution paths. It is best suited to large or complex systems that need deep analysis, compliance reporting, IDE feedback, and support for functional-safety standards.

Coverity Scan remains available at no charge for registered open-source projects. That service began through a U.S. Department of Homeland Security initiative, but Black Duck now manages it. The free service and the commercial Coverity product should be described separately so readers understand which option applies to them.

SpotBugs

SpotBugs is the actively maintained successor to FindBugs. It is an open-source static analyzer that inspects Java bytecode for bug patterns such as null-pointer mistakes, resource leaks, incorrect equality checks, and concurrency problems.

SpotBugs can run standalone or through Maven, Gradle, Ant, Eclipse, IntelliJ IDEA, and SonarQube integrations. Unlike the hosted platforms above, it does not provide a complete code-review dashboard by itself; teams normally run it in CI and publish or annotate its results through their build platform. That makes it a strong lightweight choice for Java projects that want deterministic bug detection without adopting a broader commercial platform.

Conclusion

The best automated code review setup is usually a small, complementary stack rather than one tool with every possible rule enabled. Run fast formatters and linters locally, apply quality and security gates only to changed code, and reserve human review for behavior, architecture, tradeoffs, and shared understanding.

Choose a tool that supports your languages and code host, reports findings where developers will act on them, and lets your team tune or suppress noisy rules. Then pilot it on a few repositories and measure useful findings, false positives, and feedback time before expanding it.

Static analysis is only one form of automation. For contextual, LLM-based feedback, compare the current AI code reviewers. You can also review the best manual code review tools for managing discussions, approvals, and the rest of the review lifecycle.

Official source for “13 Best Automated Code Review Tools for Static Analysis and Security (2026)”: https://www.awesomecodereviews.com/automation/automated-code-reviews/. Last updated: July 23, 2026

Bottom-Up Code Review

Thu, 25 Apr 2024 08:59:30 GMT

During a bottom-up code review, the reviewer starts with reviewing single lines of code, small blocks of code, or small individual functions. By inspecting those low-level elements, the reviewer builds an understanding of how these elements operate, how code is structured, and how those elements contribute to the system’s overall functionality.

This article covers the following:

When to use a bottom-up code review approach?
Code example for bottom-up reviewing
Step-by-step guide to review code bottom-up
Summary

Are you ready to learn more? Then sign-up, or log-in: It’s free.

Official source for “Bottom-Up Code Review”: https://www.awesomecodereviews.com/code-reading/bottom-up-code-review/. Last updated: April 25, 2024

Code Review Techniques

Thu, 25 Apr 2024 08:59:30 GMT

Here is a list of articles that help you to learn more about different code review techniques:

1. Checklist-based Code Reviews
2. 10 Best Review Techniques
3. Copilot for Automated Code Reviews
4. Test-Driven Reviews (member content)
5. Top-Down Code Review (member content)
6. Bottom-Up Code Review (member content)

Official source for “Code Review Techniques”: https://www.awesomecodereviews.com/code-reading. Last updated: April 25, 2024

10 Best Code Review Techniques

Mon, 22 Apr 2024 08:59:30 GMT

Systematically reviewing source code is an essential part of ensuring code quality and correctness of the code. Yet, most developers review their code ad hoc, which means they do not have any formal, or even explicit code review approach that they can easily describe. While a few formal code review techniques exist, they are not widely known. In this article, I show you different code review techniques you can use to make your code review approach more systematic, explicit, and effective. Those techniques are either dedicated code review techniques, or techniques from other development disciples, such as code reading, testing, or debugging, that I adapted to facilitate the task of code reviewing to help you find more bugs, and understand the code under review better.

Modern code review is ad-hoc

Most programmers review code in an ad hoc manner. This means there is no explicit, formal, or systematic process that the team agreed upon to review code. Instead, the developers intuitively review source code files based on their experience.

Which files, methods and even statements developers look at, and in which order, is up to the individual developer, and often even up to their current mood. Similarly, which aspect or issues they look for in code is not well defined, and can change from developer to developer.

Junior developers struggle without concrete review techniques

While programmers develop their individual techniques for code reviewing over time, those techniques are implicit, vary from person to person, and often only live in the developers’ heads. Junior developers therefore often wonder how exactly they should review code, and what to look for. They learn how to review code by copying and mimicking what they see their peers do in code review. However, this process to learn code reviews is neither efficient nor effective. It also means that each team member will have a slightly (or vastly) different approach to review code.

Transforming implicit to explicit knowledge

One of the best code review hacks a team can embrace is to transform the implicit knowledge that experienced developers on their team have (basically in their head), into explicit knowledge.

During such a transformation process, the experienced developer describes in detail what they do during a code review. Over time, those explicit guides to reviewing code, can become one overall guideline that describes how code is reviewed within a team. Such a guideline serves two purposes: First, it streamlines how a team reviews code, and second, it allows people new to the team to learn quickly what is important during code reviewing.

Formal, systematic, and explicit review techniques

In addition to learning from the experience of senior developers, we can also learn from formal, systematic, and explicitly described techniques for code inspection, code review and code reading.

In this blog post, I show you some of the code review techniques I also teach in my code review workshops. This can help you to transform your implicit and ad hoc reviewing techniques into explicit and more systematic approaches.

Systematic Code Review Approaches

We will look at the following systematic code review approaches:

Checklist-based Code Reviews
Test-Driven Code Reviews
Bottom-up versus Top-Down Code Reading
Control-flow versus Data-flow Code Reviews
Pattern Recognition
Cross-Referencing
Change-Impact Analysis
Trace-Based Code Reading
Abstract-Driven Code Reviews
Functionality or Use-Case-Driven Code Reviews

1. Checklist-based Code Reviews

One of my favorite code review techniques involves using a checklist. They are by far the most widely used systematic code review technique because the approach is straightforward to implement and does not involve a lot of additional effort. In empirical research, checklist-based code reviews have also been shown as very effective.

Checklist-based code reviews involve using a predefined list of items or criteria to assess the code. A checklist can focus on a variety of factors such as coding standards, design principles, security guidelines, and performance considerations. You can find a code review checklist that covers a wide range of topics here. Sometimes, only one of those factors, for example, security, is the focus of such a checklist. This makes sense when you want to perform a more thorough review in this specific area. Have a look at this security-focused code review checklist as an example.

Pros:

Provides a systematic and structured method for reviewing code, ensuring consistency and thoroughness.
Helps reviewers focus on important aspects that might be overlooked otherwise.
Assists in educating new team members about coding standards and best practices.
Functions as a memory aid, ensuring important aspects are checked.

Cons:

Correct usage of the checklist might be unclear or confusing.
Aspects not covered by the list might be overlooked.
May lack flexibility, as not all checklist items are applicable to every piece of code.
It might be not clear where to look, as no order for inspection was given.

Learn more about checklist-based reading here.

2. Test-Driven Code Reviews

During test-driven code reviews, the code reviewer starts by reviewing the test code before they review the production code. The rationale behind this approach is to use the test cases as use cases that explain the code. Thus, the code reviewer learns about the production code when they look at the test code, which helps them create a mental model. The tests are used as a specification of what the software is supposed to do, and the code reviewer learns about the assumption the code author had about the code through the tests.

Pros:

Helps improve the test code quality and thus maintainability and quality of the code.
Ensures high test coverage and quality.
Encourages writing meaningful tests that truly validate the code.
Tests can help the developer understand the production code.

Cons:

Depends heavily on the quality of the tests themselves.
Can’t be done in the absence of tests.
Tests might replicate the misunderstandings of the code author about the code’s specification.

Learn more about test-driven code reviewing here.

3. Bottom-up and Top-Down Code Reading

All code reading techniques can be broadly categorized also into bottom-up or top-down reading. Most of the time, we use a combination of those two approaches. So, let’s have a more detailed look!

Bottom-up Code Reading

Bottom-up reading means that the developer starts reading, understanding, and reviewing small fragments of the code first. Based on those small fragments, like single code statements, or small methods the developer works their way up to understand and evaluate more and more of the functionality and quality of the software under review. This way, the developer gradually builds a picture of how code elements interact to form the larger system.

Bottom-up code reviewing works well when reviewing a small, self-contained piece of code, like a function or a class. On the other hand, it also works well, when you have to review a larger piece of software you are completely unfamiliar with that lacks documentation.

Pros:

Developers build a thorough understanding of the nitty-gritty details of the code.
Helps to effectively identify local issues, bugs, and inefficiencies.
The developer needs less overall context about the system, making it suitable for new team members or for reviewing isolated components.
Works well for unclear or unfamiliar legacy code, or code that isn’t documented.

Cons:

It is a time-consuming approach due to the focus on details.
Reviewers might miss the big picture, as well as architectural or higher-level design problems.
When confronted with a large code change, starting at the lowest level can be overwhelming and inefficient.

Top-down Reading

In a top-down reading approach, the software developer starts by reading, for example, a user story or the documentation of the software first. These often non-code artifacts already explain the purpose of the code under review and give the reviewer an overview of what to expect. Then, the reviewer examines the overall structure and components of the systems. The goal is to build a mental model of the system before looking at the code in more detail. In a later step, the reviewer tries to find the most significant method(s), that drive the functionality and starts reviewing in more detail from there.

Pros:

This approach helps build an understanding of the system’s architecture and high-level design.
It is effective in spotting problems with the overall design, structure, and integration points.
The approach is suited for larger code changes or even complete codebases.
It helps prioritize which parts of the code to focus on for a more detailed review.

Cons:

Reviewers using only a top-down approach might overlook specific low-level coding issues or bugs.
Requires the reviewers to have a good understanding of the overall system, which might not be feasible for newcomers.
By examining only high-level artifacts, the reviewer might make incorrect assumptions about how high-level designs are implemented at the lower levels.

Learn more about top-down code reviews here.

Combining bottom-up and top-down code reviewing

In practice, a combination of both approaches is often used. Starting with a top-down review helps understand the system’s architecture and major components, setting the stage for a more detailed, bottom-up review of specific areas of interest or concern. This combined approach ensures the architectural integrity and the detailed correctness of the code.

4. Control-flow and Data-flow Code Reviews

Two other complementary code review approaches are control-flow and data-flow code reading. Control-flow reading follows the execution of the program, whereby during data-flow reading you follow the data.

Control-flow Code Reviews

Control-flow reading focuses on understanding how the program’s execution progresses. It examines the order in which statements, instructions, or function calls are executed and how the program moves from one part to another. This includes looking at loops, conditional statements, function calls, and recursion. Control-flow driven code reviews are great for finding logical errors.

Pros:

Highly effective in spotting logical problems with the flow of execution, such as loops, conditionals, and sequence of operations.
Essential for understanding the execution order and for debugging issues like infinite loops or unexpected branches in logic.
Helps in understanding the overall structure of the program, particularly the execution order and the interrelation of various components.

Cons:

Reviewers might miss issues related to data handling or data integrity.
It is less effective for data-intensive applications.
Complex to perform in event-driven systems due to the non-linear progression of execution.

Data-Flow Code Reviewing

Data-flow reading focuses on how data moves through the program. This includes tracking the source, use, and modification of variables and data structures, understanding how data is passed between functions, and examining how data state changes over time. Data-flow code reviewing is particularly useful when looking at the code with a security lens. It helps identify data leaks or points where sensitive data might be compromised.

Pros:

Effective in identifying problems related to data handling, such as data corruption, improper use of data structures, and issues with data lifecycle.
Particularly useful for uncovering security flaws that stem from the misuse of data, like buffer overflows or injection attacks.
Helps in tracing how data moves through the system, which is crucial for understanding complex interactions and dependencies.
Can identify inefficiencies in how data is processed, leading to opportunities for performance optimization.

Cons:

Tracing data flow can be challenging, especially in large codebases with numerous data paths and interactions.
Requires a detailed and thorough examination of how data is handled, manipulated, and transformed, which can be time-intensive.
Focusing primarily on data flow can lead to overlooking issues related to control flow, such as logic errors or incorrect program sequencing.

Combining control-flow and data-flow code reviewing

In practice, both control-flow and data-flow reading modes are often used together during code review. Understanding how data is handled (data-flow) is crucial for evaluating the logic and sequence of operations (control-flow). For example, in a function with complex logic, you might use control-flow reading to understand the sequence of operations while simultaneously using data-flow reading to see how data is manipulated throughout those operations. This integrated approach provides a comprehensive understanding of the code, helping to identify both logical errors and data-related issues.

Code Reading, Debugging and Program Understanding techniques

While reviewing code, we can make use of general code reading, debugging and program comprehension techniques. In the following, I’ll briefly highlight some of the most useful techniques.

5. Pattern Recognition

During pattern recognition, the code reviewer uses mostly a top-down approach to identify common patterns in the code. Such patterns include design patterns, algorithmic patterns, or idiomatic expressions in the programming language. Pattern recognition during code reviewing is helpful to create a mental model of the software system, but also to identify problems with the software’s architecture, or the design of algorithms.

Pros:

Helps create a mental model of the code change and the structure of the code.
Streamlines the review process and leads to more consistent review approaches even amongst different team members.
Well suited to find problems within the software architecture or design.

Cons:

Due to the focus on patterns, reviewers might overlook other problems.
Using known and common patterns to judge code, can bias the reviewers and they might dismiss good, new approaches, just because they are not established yet.
Reviewers need a broad knowledge of patterns and anti-patterns to look for.

6. Cross-Referencing

During cross-referencing, the code reviewer systematically reviews the dependencies and relationships between code elements, such as classes, functions or variables. This approach is suitable to understand the interdependencies and also the impact change can have on the system. As manual cross-referencing is a tedious task, code reviewers can use tools to extract, display or visualize this information. Most IDE’s provide built-in tools that help with cross-referencing, which is also often used during code refactoring. These tools build an index of all code elements and link them, which helps during navigation.

Pros:

Finds dependencies, and relationships and reveals how a change impacts the rest of the system.
Allows the reviewer to build a deep understanding of the codebase, and the code change under review.
Reviewers get a good understanding of the control flow and the data flow, thus allowing them to identify errors in execution and data manipulation.

Cons:

If done manually, cross-referencing is tedious and error-prone.
For larger code changes and systems might be overwhelming for the reviewer.
Focusing too much on relationships and dependencies between artifacts can lead to overlooking other issues.

7. Change-Impact Analysis

During change-impact analysis, the reviewer gathers information to be able to judge how the code change will impact the rest of the system.

While cross-referencing can be used as part of a change-impact analysis, a change-impact analysis is broader and also involves analyzing more high-level artifacts, such as specifications, documentations to understand the impact of the code change. A reviewer will normally start by understanding the rationale behind the code change, and its description (top-down). Then, the reviewer will identify affected components, analyze the dependency graph and assess the impact of this change on the functionality of the overall system. During such an analysis the reviewer should also look at the impact on the test system: does it need tests to change, or the be added?

Pros:

Discussions on the impact of code changes can improve the understanding a team has of the overall codebase.
Allows to direct reviewing efforts towards impacted and high-risk parts of the codebase.
Reduces the risk of introducing bugs or regressions.

Cons:

Change impact analysis can be very time-consuming.
The reviewer has to have already a good and deep understanding of the codebase to understand the impact.
It can lead to analysis paralysis, because the reviewer cannot completely envision all potential

impacts of this code change, and is thus reluctant to approve it.

8. Trace-Based Code Reading

Trace-based reading, often used during debugging, involves following the execution of code at runtime. The code reviewer can do this by stepping through the code in a debugger or by examining logs or output traces.

Most code reviewers use a static control-flow approach to review code, instead of this dynamic code analysis technique, that focuses on understanding how the code behaves at runtime.

This dynamic evaluation is useful when the code reviewer is puzzled by a certain part of the program, or expects a bug. It allows us to understand the state of the program at various points of execution, to track the sequence of function calls, and to observe changes in variable states over time.

Pros:

Allows the review to see how the system behaves at runtime.
Effective during diagnosing or evaluating “potential” bugs and problems.
Helps build a mental model of the code, thus helpful if the reviewer is unfamiliar with the system.
Can help catch side effects or anomalies that cannot be found during a static inspection.
Suitable for detecting performance problems.

Cons:

Setting up the reviewer’s system to run the code might be cumbersome and time-intensive.
Might distract the reviewer from actually reviewing the source code.
The review is limited to the scenarios the reviewer traces.

Academic Code Reading Techniques

Code review techniques described in academic papers aim at making code reviews more systematic. Those approaches detail exactly where a reviewer should look, the order of inspection, and also which questions to ask and issues to look for.

I summarize the approaches into two types (abstract-driven and functionality-driven) and only highlight aspects that help us to better design our own code reading and reviewing approaches.

9. Abstract-Driven Code Reviews

During abstract-driven code reading, the code reviewers read small pieces of code, and write down their understanding of the code (aka create descriptions or specifications). Then, the reviewers compare the description they created with the existing specification or documentation of the code. If there was a mismatch, they found a problem. To determine the order in which methods or functions are reviewed, academic approaches often use dependency information. Commonly, the reviewers are instructed to start with the methods that have the least dependencies on the other parts of the systems. This is in line with the bottom-up code review style.

10. Functionality or Use-Case-Driven Code Reviews

Another distinct set of reading techniques does not focus so much on the entities of the system (as described before), but rather on concrete use cases or functionality of the system. Here the aim is to check whether the code behaves correctly. For that, the reviewer first has to define use cases, and then inspect if the code implements the use cases correctly. This includes designing the preconditions for the use case, the success and failure conditions, and the exceptions. This approach reminds us of systematic testing approaches, whereby here the focus is on statically inspecting the code using control-flow and data-flow reading techniques, and not on the dynamic execution of the codebase.

Want to learn more about the presented code review techniques and see them in action? Have a look at my member-only articles on code review techniques here, or sign up for a free remote learning session.

Official source for “10 Best Code Review Techniques”: https://www.awesomecodereviews.com/code-reading/code-review-techniques/. Last updated: May 02, 2024

Test-Driven Code Reviews

Fri, 19 Apr 2024 08:59:30 GMT

Test-driven code review refers to code reviews in which tests are reviewed first. Thus the difference to ad-hoc code reviewing is mainly the order in which files, functions and methods are examined.

One of the first mentions of test-driven code review was on Google’s testing blog. Since then, the idea of reading tests first during code reviews has also been empirically validated.

This article covers the following topics:

Use Test-driven reviews to find more bugs
Fewer maintainability issues are reported
Benefits of reviewing tests standalone
Tests are perceived as less important
The value of high-quality test suites
How to perform a test-driven code review?
Code example: Calculator
Reviewing calculator in a test-driven way
Variation of test-driven code reviews
Lessons learned: Review order matters and review intent is key

Are you ready to learn more? Then sign-up, or log-in: It’s free.

Official source for “Test-Driven Code Reviews”: https://www.awesomecodereviews.com/code-reading/test-driven-code-review/. Last updated: April 19, 2024

Top-Down Code Review

Mon, 29 Jan 2024 08:59:30 GMT

During a top-down code review, the reviewer begins by looking at the high-level artifacts of the system, such as ticket description, architecture diagrams or documentation. Then, they progressively drill down into more detailed aspects of the code.

Most developers nowadays start with a top-down approach, by first reading the code review description (aka. the pull request summary), or the related ticket or user story, before they start to examine the code.

This article covers the following:

When should I use a top-down code review approach?
Top-down code review artifacts
- PR description
- Python code
Step-by-step guide on how to review code top-down
Summary: Top-down code review

Are you ready to learn more? Then sign-up, or log-in: It’s free.

Official source for “Top-Down Code Review”: https://www.awesomecodereviews.com/code-reading/top-down-code-review/. Last updated: January 30, 2024

Developer Experience: Does it Matter?

Fri, 19 Jan 2024 08:59:30 GMT

Over the last few years, more and more developers and researchers look at developer experience, that is how developers think about, feel about, and value their work. This is important because for example friction that developers experience through cumbersome tools, or processes and policies that get into their way, reduce developer experience drastically, and arguable lead to a loss of productivity.

But is that so? Does developer experience have an impact on performance, productivity and even for on the ability of an organization to meet its goals?

In a recent study, we investigated exactly this question and shed light on whether measuring and improving DevEx is important for outcomes related to developers themselves (individuals), their teams, and their organization. Let me summarize the paper for you, or read the full version here.

Friction in a developer’s day is abundant

Software developer faces numerous distractions and unclear tasks on an ongoing basis: Long-turn around times for code reviews, flaky test that fail the pipeline, unclear ticket description. All those problems are well-known by many developers and lead to frustration and inefficiency. Yet even larger issue in the development lifecycle that lead to inefficiencies and fill a developers day with unnecessary obstacles, are often overlooked by upper management.

Management struggles to grasp DevEx

Developer experience (DevEx) is a direct concept that allows to detect, measure, discuss and improve such problems in the software development lifecycle. Yet, despite its importance, DevEx faces skepticism from some business stakeholders, and developers and developer experience or platform teams often struggles to get management to commit to improving DevEx. Especially management that isn’t that familiar or involved with programming and the problems developers face asks whether DevEx is crucial and a must for investment, or if it is just a nice to have, that can be ignored.

Quantifying DevEx Outcomes

Thus, in this research we investigate outcomes of DevEx on individual, team, and organizational dimensions.

Developer Outcomes: These include job performance, creativity, and learning, with the premise that improved work design leads to better outcomes for individual developers.
Team Outcomes: Focused on the quality of the system the team works in, including aspects like code quality and technical debt.
Organization Outcomes: These outcomes include retention, innovation, profitability, and the organization’s ability to meet its goals.

Model of DevEx

For this study, we introduce a model for understanding and measuring DevEx, that follows closely the framework we introduced in our earlier work here. It conceptualized DevEx through three dimensions:

Flow State: Refers to a mental state of deep immersion and focus in work.
Feedback Loops: The speed and quality of information in a system used as input to another part.
Cognitive Load: The amount of mental processing required for a developer to complete a task.

DevEx makes an Impact

Our study presents evidence that improving DevEx has positive outcomes not just for developers but also for teams and organizations.

Developers who have a significant amount of time for deep work feel 50 percent more productive compared with those lacking in dedicated focus time.
When developers feel engaged, they also feel they are 30 percent more productive, compared with developers who find their work boring.
If the code is understandable developers feel 42 percent more productive than developers that indicate their code base is hard to understand.
Developers who find their tools and work processes intuitive and easy to use feel they are 50 percent more innovative compared with those with opaque or hard-to-understand processes.
Developers who report fast code-review turnaround times feel 20 percent more innovative compared with developers who report slow turnaround times.
Tight feedback loops have another positive outcome. Teams that provide fast responses to developers’ questions report 50 percent less technical debt than teams whose responses are slow.

Where to go from here

It emphasizes the need for organizations to understand and invest in DevEx.

Concrete steps for advocating such DevEx investment include:

collecting data on the current DevEx,
setting goals based on this data,
preparing teams for success, sharing progress, and continuously revisiting and refining the approach.

To read the complete study, please visit the ACM website here.

Official source for “Developer Experience: Does it Matter?”: https://www.awesomecodereviews.com/devex/developer-experience-impact/. Last updated: January 19, 2024

Developer Experience: What Drives Productivity?

Mon, 18 Dec 2023 08:59:30 GMT

Engineering leaders have long sought to improve the productivity of their developers, but knowing how to measure or even define developer productivity has remained elusive. Past approaches, such as measuring the output of developers or the time it takes them to complete tasks, have failed to account for the complex and diverse activities that developers perform. Thus, the question remains: What should leaders measure and focus on to improve developer productivity?

Today, many organizations aiming to improve developer productivity are finding that a new developer-centric approach focused on developer experience (also known as DevEx) unlocks valuable insights and opportunities. Gartner Inc. reports that 78 percent of surveyed organizations have a formal DevEx initiative either established or planned. Accordingly, there has been a continued rise in dedicated DevEx and platform teams being formed to help improve developer experience within their organizations.

Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. A 2020 McKinsey study found that companies with better work environments for their developers achieved revenue growth four to five times greater than that of their competitors.

This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.

Continue Reding this article on ACM or download it as PDF.

Official source for “Developer Experience: What Drives Productivity?”: https://www.awesomecodereviews.com/devex/developer-experience-acm/. Last updated: December 18, 2023

What is Developer Experience (DevEx)?

Mon, 18 Dec 2023 08:59:30 GMT

Over the last two years, I have been investigating developer experience - that is, how developers experience their work and how that influences outcomes such as productivity, code quality, or retention.

In our first in-depth study, we look at which factors influence developer experience. We found 25 factors that developers regularly described when they talked about developer experience and grouped them into 4 categories:

Development and release
Product management
Collaboration and culture
Developer flow and fulfillment

We also identified how developer experience can be improved and which strategies developers have to improve it, as well as which challenges and barriers they face when they try to improve DevX.

Developers started to talk about DevX

Our research was published in mid-2022 (you can download the full paper here), and since then, a lot of people in the industry have started to talk about developer experience. This is awesome!

Developers all around the world could relate to our findings and echoed that they indeed need good developer experience to be productive and ship high-quality code. Developers know that they need time to focus and do deep work. They know about flow state and how fast code review turnaround times are a game changer.

DevX drives productivity

In a recent article, we published on ACM, we talked about how developer experience can be described with three dimensions. Those dimensions are flow state, feedback loops, and cognitive load. In this article, we also briefly highlight how to measure DevEx, and give example metrics that cover all three dimensions. We also cover case studies from companies we worked with, such as eBay, and Pfizer to demonstrate how they use metrics to understand their internal developer experience.

DevX? No buy-in from management

But while developers quickly grasped the importance of developer experience, business folks were too far away from programming to understand the significance DevX has on business outcomes. The fact is that many companies are only willing to spend money on DevX during “good“ times — when we have too much time, too much money, and no other priorities. Well, those times do not exist, especially not with a bad DevX.

When talking to engineering leaders, we realized that what is missing is data that quantifies the impact of DevX. That’s why we have worked on getting this data over the last year. Data that shows the impact of DevX on productivity, code quality, retention, innovation - well, all the outcomes that business cares about.

Hard numbers to convince business

Our research article will be published soon. The research goal was to quantify DevX’s impact on developers, teams, and organizations. The picture below highlights how improvements to the flow state of developers, their cognitive load, and the feedback loops they encounter have a direct and quantifiable impact.

Code Review Related DevX

Another interesting outcome of this study is that we could show that a smooth code review process impacts productivity, retention, and learning. As you see in the quote below, code reviews also impact innovation.

A fast code review turnaround time leads to a 20% increase in innovation.

If we think about it, it makes sense. Innovation suffers if we have to wait a long time to get feedback on our work or if releasing new features is painful.

How to Improve Code Review Turnaround Times

But which strategies help to increase turn-around times? Well, that depends on the underlying root cause for the slow feedback. But have a look at the code review best practices to find some universal strategies to improve your code review practice.

Official source for “What is Developer Experience (DevEx)?”: https://www.awesomecodereviews.com/devex/introduction/. Last updated: December 18, 2023

Code Review Challenges That Slow Your Team Down

Sat, 29 Jul 2023 08:59:30 GMT

Many teams face challenges when conducting code reviews. In this article, we will look at the most common and problematic code review challenges and also outline how to overcome those.

Code review is an engineering practice used by many high-performing teams. And even though this software practice has many advantages, teams regularly face problems doing code reviews that slow down software development.

Knowing which problems arise during code review can help you to ensure a productive and effective code review experience. The code review challenges presented in this article are based on a survey we conducted at Microsoft with over 900 participants and on my years-long experience giving code review workshops.

A typical code review process

A typical tool-based code review process looks roughly like this:

Once a developer has finished a piece of code, she prepares the code for being submitted for review. Then, she selects reviewers who should review this code change. The reviewers then inspect the code and give feedback. The author of the code looks through the feedback and improves and changes the code if need be. Once everybody is satisfied, or an agreement is reached, the code can be checked into the common code base.
In another post, I described what a typical code review process looks like at Microsoft. And here, I describe how Google reviews code.

Code reviewing isn’t always a smooth process

These steps read like a smooth process. But, like everything, things are more complicated than expected. There are quite a few code review challenges that can reduce the positive experience with code reviews for the entire team and take a toll on the team’s productivity. So, let’s have a look at the difficulties and challenges of code reviews.

The biggest code review pitfalls are about the time spent on code reviews and the value code reviews provide.

Code reviews are only effective, valuable and fun, if you receive feedback in a timely manner. Click To Tweet

Waiting for code review feedback

One of the most frustrating problems during code reviews is waiting for code review feedback. Code reviews are only fun, effective, and valuable if you receive feedback in a timely manner. Waiting for the code review feedback to come in means that you are not able to work on the code in the meanwhile. So you either spend your time scrolling through Twitter, or you have to do a context switch and work on another task. Both can be a huge problem. Even though developers can pick up other tasks to work on, if the code review takes too long, it impacts the developer’s productivity and also the developer’s satisfaction.

But why does the code review feedback take so long?

Code reviews are a “necessary evil”

Code review is not the only task the developers have to perform. Even worse, in most companies and teams, developers’ main task is to write code, not to review code. This means that code review has a lower priority to developers than working on features. Depending on the incentives and how different tasks are valued in a team, code review might come even behind writing tests or attending meetings. In fact, at several companies, code reviews are seen as a “necessary evil”.

In addition, code review can take a significant amount of time in a developer’s day-to-day work. So, it is likely that the code reviewer is engaged in other activities and has to stop or finish those first before looking at the code review.

If the timing is not ideal, and especially if the code reviewer hasn’t expected this change to come along, chances are it will take a while before she looks at the review. Remote teams also have to be aware of time zone differences. Otherwise, code reviews might even take longer.

Code reviews are not counted as actual work

Time constraints are real, and they affect both the code reviewer and the author of the code. Doing a proper code review takes time. If teams want developers to do code reviews but do not value or count the time developers spend on code reviews, this becomes a real problem.

You can’t expect quality code reviews if you don’t value the time a developer spends on them. Click To Tweet

Doing code reviews is not rewarded

It does not help to claim to value code reviews if you do not reward the effort developers spend on this task. Many companies focus on rewarding developers for the amount of code they write or the features they develop. This decreases the motivation and the ability of developers to do a good job helping each other (which includes code reviewing). Code review performance should be a cornerstone for performance evaluation or promotion decisions.

If you want your team to do code reviews well, reward them for their work. Click To Tweet

Missing guidelines on code reviews

Another code review challenge is missing guidelines or training on how to do code reviews. If developers have no clear idea of what is expected from them during a code review, they also might procrastinate on doing code reviews. This increases the time spends waiting on review feedback. In addition, it reduces the value of the feedback because developers have no clear instructions on what to look for. Training on code reviews, which creates a shared understanding of the goals of code reviews, and how to do them, helps to overcome this challenge. In addition, teams can use code review checklists to guide developers through code reviews and make code review more systematic and effective.

I’m expected to participate, but I’m not quite sure how. I’ll wait until someone else starts.

(study participant)

Large reviews are hard to review

Large code changes, that span several files and consist of more than 400 lines of code create another significant code review challenge. Imagine you are the reviewer, and you just got a code review request. You think: “I am quickly going to look at that”. But once you open the review, you see this large code change. Several files have been changed, and all changes tangle throughout the code base. What’s your first reaction?

Probably: holy cow!

10 lines of code = 10 issues.

500 lines of code = “looks fine.”

Code reviews.

— I Am Devloper (@iamdevloper) November 5, 2013

That’s right. That is exactly what we saw when analyzing thousands of code reviews. Not only does review time increase with the size of the code change, but also feedback quality decreases. Well, that’s probably understandable. Large code changes are incredibly difficult to review.

Large code reviews are hard to review. The quality of the review decreases with the size of the change, thus limiting the value teams get out of from code reviews. Click To Tweet

Reviewer is unfamiliar with codebase or technology

If, in addition, the code reviewers are not that familiar with the part of the code base the change took place in, reviewing can quickly become a nightmare. Similarly, if the reviewers are new to the technology or programming language, reviews are challenging for the reviewers. Do not expect developers that haven’t seen this piece of code before to make significant improvements.

No description of the code change is given

Understanding code changes, and especially the motivation for a code change is another code review challenge many reviewers face. If there is no description explaining the purpose of the change, code reviewing becomes much harder. We saw in the study that if the code reviewer does not understand the code change, or if she is overwhelmed by the amount of change, she cannot give insightful feedback.

It’s just this big incomprehensible mess… then you can’t big,add any value because they are just going to explain it to you and you’re going to parrot back what they say.

interviewed developer13

Not getting valuable feedback

Without a doubt, spending time on code reviews and not getting useful feedback back, is a problem. Even though the team might still benefit from the knowledge transfer, the developer’s motivation to send their code for review decreases when they do not get valuable feedback.

There are several reasons why reviewers do not or can’t give insightful feedback. It can be that the code reviewer did not have the right expertise. Another common reason is that the reviewer did not have enough time to look thoroughly through the change.
Maybe the code reviewer does not understand the code. It can also be that the code reviewer does not know what issues to look for. Understanding what makes for valuable code review feedback, using a code review checklist, and implementing code review best practices help to make sure the code author gets valuable feedback back.

Focusing on stylistic issues

Another problem that can happen during a code review is called bikeshedding. Bikeshedding means that developers focus on smaller issues and start disputing minor problems and overlook the serious ones. The reasons for that are manifold. Common behind-the-scenes challenges that lead to bikeshedding are that developers do not understand the code change or that they do not have enough time for the code reviews. Sometimes bikeshedding can be a sign that there are issues with the team dynamics.

If people dispute about minor issues during code reviews, take a look at the underlying issue. Time pressure, too large reviews, rivalry? Click To Tweet

Reaching consensus

Sometimes it is hard to reach a consensus. This can occur between code reviewers and the code author, or also between several code reviewers directly. Such situations must be handled carefully as team dynamics are closely connected to these happenings. Communication via tools and in written form can aggravate this problem. If there seems to be any tension, or contentious issues to discuss, switching to face-to-face (either in person or via a video call) might be a good idea.

The benefits of code review outweigh the effort

I hope this list of code review challenges did not change your mind about code reviews. Because, the good news is that if you are aware of the problems during code review and take precautions, code reviews are a very beneficial engineering technique. And, there are even more proven ways to work effectively with code reviews.

So, keep reading more about code reviews, for example about code review best practices to overcome the code review challenges and ensure your team gets the best out of the code review practice.

Official source for “Code Review Challenges That Slow Your Team Down”: https://www.michaelagreiler.com/code-review-pitfalls-slow-down/. Last updated: January 17, 2023

Specific Code Review Checklists

Sun, 26 Feb 2023 22:40:32 GMT

Code review checklists make code reviews more systematic and help detect more issues. They also help teams to perform code reviews more consistently among team members.

Yet, there is no one size fits all code review checklist. Instead, the best code review checklist is specific to your technology, domain and to what you want to check the code for. This means it’s best to tailor code review checklists to your needs.

In the remainder of this article, you find code review checklists that focus on different areas, like security or accessibility, or different technologies, such as Java or C. You can use those code review checklists for inspiration and derive your own one based on those example code review checklists.

General Code Review Checklists

General Code Review Checklist: This list covers all relevant aspects from implementation, to readability and security.
Short Code Review Checklist by Suremder Reddy Gutha: Short code review list with nice visualization.

Company Code Review Checklists

Squarespace Code Review Checklist

Security Related Code Review Checklists

Security-focused code review checklist: A good balanced code review checklist that covers all relevant topics of the OWASP top 10, such as input validation, authorization or session management.
OWASP Web Application Security Testing Checklist: A web application checklist by OWASP
Security Audit Checklist: Code Perspective from University of Washington: General tips from two perspectives: Programmer and Attacker. Also tips specific to Ruby/Java/JSP/PHP
Secure Code Review Checklist: Modelled after OWASP.

Java Code Review Checklists

30+ items for Reviewing Java Code: A checklist with concrete examples, covering aspects relevant to object-oriented programming.
Java Code Review Checklist from DZone: Concrete list for Java.
Java Concurrency Checklist: An in-depth resource dedicated to Java concurrency best practices.

JavaScript Code Review Checklists

C# Code Review Checklists

Short List of rules C# Code

C++ Code Review Checklists

Checklist referencing sources

Python Code Review Checklists

Python Code Style with examples

Pull Request Checklist

Frontend pull request checklist: This a meta checklist that makes sure you have done all necessary checks before your frontend code goes through a pull request.

Official source for “Specific Code Review Checklists”: https://www.awesomecodereviews.com/checklists/topic-based-code-review-checklists/. Last updated: February 26, 2023

Company Specific Code Review Practices

Sun, 26 Feb 2023 08:59:30 GMT

Over the years, I curated a list of articles that give insights into how companies like Facebook, Google, or Netlify review code. On their engineering blogs, those companies share their code review values, or which tools they use. We also find insights into how other companies incorporate static or dynamic analysis, or how they deal with the problem of nit-picking.

In the following, you find summaries of the insights different companies share about their code review practices, as well as a link to the complete article.

Auth0

The code review guide of Auth0 focuses on the automation aspects, and also gives clear indications which quality criteria a pull request must pass before it is reviewed manually.

BitCoin Core

This guide examples how newcomers can help in reviewing pull requests in the BitCoin Core project and has an emphasis on distinguishing between core issues and nitpicking.

Facebook

Facebook makes heavy use of static analysis tools. This researchy article goes into the details of how they scaled static analysis at Facebook using tools such as Infer and Zoncolan, and how to apply techniques similar to program verification in practice.

Gitlab

Gitlab’s engineers are very open about their desired engineering culture, their values, and how they do things. In this section of the Gitlab handbook, they outline their Code Review Values.

Google

Google’s main principle is enabling lightning-fast code reviews. How Googlers achieve a code review turn-around time of 4 hours, and what their practice and policies are like are detailed in this article about code review at Google. Google’s official code review guidelines also state when they consider code good enough, or what to do when there is a conflict.

Microsoft

Microsoft does not have one way to do code reviews. Instead, teams or divisions review code depending on their specific needs, requirements, processes and constraints. Yet, Microsoft developers have a few best code review best practices that prove helpful to enable fast and effective code reviews independent of the system developers work on or the engineering processes they employ.

Netlify

Netlify describes how they use specific words to indicate the severity of the issues raised during code reviews. They use something they call the “feedback ladder”, which encodes severity in form of a “stone” metaphor. In their case, “sand” for example would indicate a minor issue that you can or cannot address during code reviews, and “rock” indicates a major issue you surely should work on.

Netflix

Netflix describes how they review tests and test outcomes during pull requests, as well as how they worked on improving their confidence in test results.

New Relic

New Relic had a team with very experienced engineers that soon turned on each other during code reviews. Passive-aggressive communication dominated the code reviews. After several people even left the team, they decided to refine their code review process from the ground up. They specified who is responsible for what, and require the code reviewers to separate subjective and objective code review feedback by labeling it “blocking” or “non-blocking”.

Palantir

Palantir describes how they do code reviews, in a guide that explains why Palantir does code reviews, when they do code reviews, and how they prepare and perform code for review, and also gives some code review examples.

Quora

Quora describes how they use post-commit reviews to increase speed. It’s common practice at Quora to push code without review (several times a day) to production. The rule of thumb is that this code should be reviewed within one week, but most of the code is reviewed within 1-2 days after it went live into the production system.

PayPal

PayPal developers outline their take on code reviews. The most interesting part of their guide is their focus on learning and mentoring. In fact, code reviews at PayPal are seen as free career improvement training.

Plaid

At Plaid, the Code Review Culture aims to allow for learning and growth of all parties and ship healthy code.

Raycast

Raycast on the other hand describes how they do not do code reviews by default. They think that pull requests lead to distrust in the team, and that the code author should take full responsibility for their changes.

Shoptify

Shopify describes how small, coherent pull requests help them to not live in fear for several months.

Software Improvement Group

The Software Improvement Group also outlines how they use Gitlab to do code reviews, and which rules and policies they incorporate in their code review practice.

Squarespace

Squarespace published about their code review culture in a two parts blog article: Code Review Culture PartPart 1 + Code Review Culture Part 2

Contribute to this list

If you have an article you think should be added, please open a PR here, or send it to me via email. Thanks.

Official source for “Company Specific Code Review Practices”: https://www.awesomecodereviews.com/companies/company-specific-code-review-practices/. Last updated: February 26, 2023

Automatic code review descriptions with "Whatthediff" code review tool

Sat, 18 Feb 2023 08:59:30 GMT

Whatthediff is a code review tool that analyses your code and generates a summary of the source code changes in plain English. This rather small but focused code review helper tool neatly enhances GitHub’s code review functionality.

Precise Code Review Descriptions enable Good Code Reviews

Writing good code review descriptions, and explaining the changes to the code reviewers, is a great code review practice. In particular, it helps to overcome the expert blind spot. The expert bling spot describes the problem that the code author knows so much about what they worked on that their code change seems trivial to them. Yet, for a code reviewer who has not worked on this code before, building a mental model of the code changes takes a lot of cognitive effort. The code reviewer has to analyze the files, see what changed, and gradually build an understanding the code change. A code review description can help to reduce this effort and enables the reviewer to give better feedback.

Code review descriptions are often sparse

While working with many engineering teams, I saw that many developers and teams do not provide good enough code review descriptions. Instead, the description of the code change is often a one-liner followed by a bullet-point list of all the commit messages. Here, this little tool can help to ehnance the pull request with a summary of the changes. This summary then can not only help the code reviewer understand the change, but also the code author to remember what they did. Based on this memory aid, the code author can then fill in the blanks that the tool can not know, like why they chose a certain approach, or what the reviewer should focus on and enhance the code review description with this information.

Refactoring feature of the whatthediff code review tool

Whatthediff is like ChatGPT, or GitHub Co-pilot, but focuses on improving the reviewability of your pull requests. The tool developers also work on other cool features, like the automatic refactoring of code. Whenever you see code that you think should be refactored, you comment with “/wtd” and describe the change you want to see, and let the tool take care of the rest.

Tool Verdict

My take on the whatthediff code review tool is that it’s indeed a nice little code review helper if you are not worried about IP issues (you have to grant the tool full excess to your source code). I added it to my toolbox for my open-source projects, and I’m always curious to see how well it describes my changes. Often, I’m surprised that it neatly describes all the changes and even a bit of the intention of the code. Other times, it generates rather unhelpful change descriptions like “File changed”. Yet, overall I’ve had many good and helpful change summaries that make for a great tool experience.

Change summaries are not enough

The most important critique is that change summaries are only one part of a good code review description. Other important aspects of code review description, like an explanation of why this change is needed, or guidance for the code reviewer on what they should focus on cannot be generated by the tool. Yet, as described before, the automatic summary can also serve as a memory aid for the code authors and help them fill in the blanks.

Right now, it only works with GitHub, but I’m pretty sure that we will see integrations with other code review tools soon. If you want to check it out, you can find the whatthediff code review tool here.

Official source for “Automatic code review descriptions with "Whatthediff" code review tool”: https://www.awesomecodereviews.com/tools/code-review-descriptions-what-the-diff/. Last updated: February 18, 2023

Automated Code Reviews

Thu, 16 Feb 2023 08:59:30 GMT

To learn more about automation in code reviews read the following articles:

Official source for “Automated Code Reviews”: https://www.awesomecodereviews.com/automation. Last updated: February 22, 2023

Developer Experience

Thu, 16 Feb 2023 08:59:30 GMT

To learn more about developer experience read the following articles:

Official source for “Developer Experience”: https://www.awesomecodereviews.com/devex. Last updated: February 22, 2023

Code Reviews at Companies

Tue, 14 Feb 2023 08:59:30 GMT

Learn how market leaders like Microsoft, Google or Spotify do code reviews.

Official source for “Code Reviews at Companies”: https://www.awesomecodereviews.com/companies/. Last updated: January 14, 2023

Dynamic Application Security Testing

Tue, 14 Feb 2023 08:59:30 GMT

Dynamic Application Security Testing (DAST) is a method of testing the security of an application by examining its behavior while it is running. It involves simulating real-world attacks and interactions with the application to identify security vulnerabilities and potential exploits.

When to use DAST

DAST is typically used after an application has been deployed, when it is running in a live environment. It is a complementary technique to Static Application Security Testing (SAST), which analyzes source code before deployment. DAST is particularly useful for identifying security vulnerabilities that cannot be detected through code analysis alone, such as configuration issues, input validation problems, and session management issues.

Who should do DAST

DAST can be performed by security professionals, penetration testers, or developers. However, it is usually performed by security professionals who have the expertise and experience to perform this type of testing.

How to do DAST

There are several steps involved in performing DAST:

Planning: Define the scope and objectives of the DAST test.
Preparation: Set up the testing environment, including the application, network infrastructure, and test tools.
Scanning: Perform the actual test by simulating real-world attacks on the application and analyzing its behavior.
Reporting: Analyze the results of the test and produce a report that includes a list of vulnerabilities, their severity, and recommendations for remediation.
Remediation: Fix the identified security vulnerabilities, and re-test the application to ensure that it is secure.

DAST and code review

Dynamic Application Security Testing (DAST) is not typically done during code review, as code review is focused on the quality and maintainability of the code, whereas DAST is focused on the security of the application as it is running. Code review is usually performed during the development phase before the application is deployed, while DAST is performed after the application has been deployed.

Shifting security left

However, it is possible to integrate security considerations into the code review process by incorporating both code analysis (such as SAST) and dynamic testing (such as DAST) into the development process. By doing so, organizations can shift security left and catch security vulnerabilities early in the development cycle, reducing the risk of data breaches and ensuring that their applications are secure.

Popular DAST tools

OWASP ZAP: An open-source DAST tool that is easy to use and provides a graphical user interface for performing automated security scans.
Nessus: A commercial DAST tool that offers both vulnerability scanning and penetration testing capabilities.
Burp Suite: A commercial DAST tool that provides a comprehensive set of features for performing web application security testing.
Acunetix: A commercial DAST tool that is specifically designed for web application security testing and provides both vulnerability scanning and manual testing capabilities.
Qualys Web Application Scanning: A commercial DAST tool that provides both vulnerability scanning and penetration testing capabilities.
WebInspect: A commercial DAST tool that provides comprehensive web application security testing capabilities, including vulnerability scanning and penetration testing.

Conclusion

DAST is a valuable technique for testing the security of an application and identifying security vulnerabilities that cannot be detected through code analysis alone. By performing DAST, organizations can reduce the risk of data breaches and ensure that their applications are secure.

Official source for “Dynamic Application Security Testing”: https://www.awesomecodereviews.com/security/dynamic-application-security-testing/. Last updated: February 14, 2023

Static Application Security Testing

Tue, 14 Feb 2023 08:59:30 GMT

Static Application Security Testing (SAST) is a software testing technique that aims to identify security vulnerabilities in an application’s source code before it is deployed. SAST is performed at an early stage of the software development lifecycle and helps to find and fix security vulnerabilities before they can be exploited. Using static analysis tools during code reviews, and integrating them in your CI/CD pipeline is a code review best practice and helps to improve the reliability and security of applications, as well as to reduce the manual inspection time during code reviews.

When to use SAST

During development: SAST can be used throughout the development process to identify and fix security vulnerabilities early on, reducing the risk of these issues being introduced into the production environment.
As part of a security audit: SAST can be used as part of a security audit to check an existing application’s source code for security vulnerabilities.
Before deployment: SAST can be used to check the source code of an application before it is deployed, to ensure that it does not contain any security vulnerabilities that could be exploited in the production environment.

How to perform SAST

Prepare the code: The source code of the application should be made available for analysis.
Choose a SAST tool: There are many SAST tools available, each with its own features and capabilities. Choose a tool that best fits your needs and the specific requirements of your application.
Configure the tool: Set up the SAST tool, including configuring any custom rules or security policies that need to be enforced.
Run the SAST analysis: Start the SAST analysis by running the tool on the source code. The tool will scan the code and identify any security vulnerabilities or code issues.
Review the results: Review the results of the SAST analysis to identify any security vulnerabilities or code issues.
Fix the vulnerabilities: Fix the security vulnerabilities by making the necessary changes to the source code.
Repeat the analysis: Repeat the SAST analysis until all security vulnerabilities have been fixed.

SAST during code review

To automate the process of identifying and fixing security vulnerabilities in the source code, SAST can be integrated into the code review process.

SAST tools can be integrated into the code review process, allowing for automated scanning of code changes before they are committed to the repository. Automating the security analysis reduces the time and effort required for manual code review. In addition, static analysis tools are often much more reliable to find certain security issues. Another benefit of integrating SAST into the code review process is that security assessments can be performed continuously, ensuring that security vulnerabilities are detected and fixed as soon as they are introduced. It also helps to improve collaboration between developers, security teams, and stakeholders by providing a clear and comprehensive report of security vulnerabilities and code issues.

Shifting security left

Shifting security left refers to the practice of integrating security considerations into the early stages of the software development lifecycle, rather than waiting until later stages when it may be more difficult and expensive to address security issues. Integrating Static Application Security Testing (SAST) during code reviews performed by developers is a key aspect of shifting security left, as it allows security vulnerabilities to be identified and fixed as soon as they are introduced into the codebase.

SAST tools

Checkmarx: Checkmarx is a comprehensive SAST tool that provides advanced code analysis capabilities, including support for multiple programming languages, deep code scanning, and a user-friendly interface.
SonarQube: SonarQube is a popular open-source SAST tool that provides automatic code analysis and reporting, including support for multiple programming languages, integration with multiple tools and platforms, and an extensive library of custom rules and plugins.
Veracode: Veracode is a cloud-based SAST tool that provides a complete suite of security solutions, including support for multiple programming languages, automatic scanning and reporting, and integration with popular development tools.
Fortify: Fortify is a SAST tool that provides advanced code analysis capabilities, including support for multiple programming languages, deep code scanning, and integration with popular development tools.
Synopsys: Synopsys is a SAST tool that provides deep code analysis and reporting, including support for multiple programming languages, integration with popular development tools, and a user-friendly interface.
Coverity: Coverity is a SAST tool that provides deep code analysis and reporting, including support for multiple programming languages, integration with popular development tools, and a user-friendly interface.

Static analysis tools and security scanner

CodeQL: Semantic code analysis engine to detect security vulnerabilities
PMD: An extensible cross-language static code analyzer
Semgrep: Security scans during continuous integration

Conclusion

In conclusion, SAST is an important technique for improving the security of applications. By identifying security vulnerabilities in the source code before deployment, SAST helps to reduce the risk of these issues being exploited in the production environment. SAST is performed by using a SAST tool to scan the source code and identify security vulnerabilities, which are then fixed by the development team.

Learn also about dynamic application security testing, equip yourself with an awesome secure code review checklist, and read about the 10 best code review tools.

Official source for “Static Application Security Testing”: https://www.awesomecodereviews.com/security/static-application-security-testing/. Last updated: December 05, 2023

Code Review Tools

Tue, 14 Feb 2023 08:59:30 GMT

To learn more about code review tools read the following articles:

Official source for “Code Review Tools”: https://www.awesomecodereviews.com/tools/. Last updated: January 14, 2023

Scanning for security vulnerabilities with CodeQL

Tue, 14 Feb 2023 08:59:30 GMT

CodeQL is GitHub’s static analysis engine for finding security vulnerabilities and coding errors. It extracts a relational representation of a codebase into a CodeQL database, then runs queries against that database. The representation includes syntax, types, control flow, and data flow, so queries can follow values across a program instead of matching text alone. CodeQL does not “understand the developer’s intent,” and a clean scan does not prove that an application is secure.

CodeQL complements, rather than replaces, manual practices such as using a secure code review checklist. GitHub’s CodeQL overview explains the analysis model in more detail.

Who should use CodeQL

CodeQL can be used during development, in continuous integration, while reviewing pull requests, and as part of static application security testing. Most teams can start with GitHub’s maintained queries; writing custom queries is optional.

Developers and reviewers can use code scanning alerts to inspect a finding, trace data-flow paths, and discuss or fix the affected code. Security specialists can develop custom queries for organization-specific vulnerability patterns or use CodeQL for variant analysis: finding other instances of a known vulnerability pattern.

How to use CodeQL

You do not need to install the CodeQL CLI or write queries to start using CodeQL on GitHub. There are three common setup options:

Default setup: Enable CodeQL in the repository’s code security settings. GitHub detects supported languages, selects a build mode, and creates the scanning configuration. This is the recommended starting point for eligible repositories.
Advanced setup: Commit a GitHub Actions workflow when you need control over languages, build steps, triggers, runners, query suites, or custom query packs.
CodeQL CLI: Create and analyze CodeQL databases locally or in an external CI system. Results can be exported as SARIF and uploaded to GitHub code scanning.

GitHub documents the tradeoffs in About setup types for code scanning. Code scanning with CodeQL is available for public repositories on GitHub.com. Private and internal repositories need to be owned by an organization on GitHub Team or GitHub Enterprise with GitHub Code Security enabled.

On GitHub, an alert can include the affected location, severity, an explanation, data-flow paths when relevant, and guidance for fixing the problem. Copilot Autofix may also suggest a change for supported queries, but it does not produce a fix for every alert and generated fixes still require review and testing.

CodeQL during code review

With pull-request scanning enabled, findings can appear in the Code scanning results check and as annotations on changed lines. A finding is shown on a pull request only when all lines identified by the alert are present in the pull-request diff, so reviewers should not treat the annotations as a complete assessment of the repository.

Teams can configure which severity levels fail the check and can make the check required through branch protection. Reviewers should still validate whether a result is exploitable, whether a proposed fix is safe, and whether tests cover the change. See GitHub’s guide to triaging code scanning alerts in pull requests.

CodeQL integration and supported languages

CodeQL currently supports:

C and C++
C#
Go
Java and Kotlin
JavaScript and TypeScript
Python
Ruby
Rust
Swift
GitHub Actions workflows

CodeQL does not support every programming language; for example, PHP and Scala are not currently supported. Check GitHub’s current CodeQL language list before planning a rollout.

GitHub Actions is the most direct integration on GitHub. Advanced setup can also run on self-hosted runners, while the CodeQL CLI supports external CI systems.

Predefined queries

GitHub maintains two built-in query suites:

default prioritizes high-precision security queries and aims to keep false-positive results low.
security-extended includes the default suite plus additional queries with slightly lower precision and severity, so it may find more issues but can also produce more false positives.

These queries are distributed in CodeQL query packs; they are not stored in the CodeQL database. The database contains the representation extracted from the codebase. GitHub maintains a current comparison of the built-in query suites.

Custom queries

The built-in suites do not cover every application-specific security rule. CodeQL’s QL language lets security specialists create queries for a known vulnerability pattern or an organization’s policies. Queries and libraries can be grouped and shared as CodeQL packs.

Use advanced setup to add custom query packs to GitHub code scanning. The CodeQL CLI and the CodeQL extension for Visual Studio Code are intended for developing and testing queries. Custom queries should be tested for precision before they become merge-blocking checks; a noisy rule can train reviewers to ignore useful alerts.

CodeQL example

CodeQL includes language-specific queries for several forms of cross-site scripting (XSS). An XSS query can track untrusted data from a source, such as an HTTP request, through the program to a sink that renders HTML or JavaScript. If the path does not pass through a recognized sanitizer, CodeQL may report it and show the data-flow path. The alert is a starting point for review: a reviewer still needs to confirm the trust boundary, framework behavior, and whether the data is safely encoded for the output context.

Summary

CodeQL is a query-based static analysis tool that integrates closely with GitHub code scanning. Default setup is the simplest route for most eligible repositories; advanced setup and the CLI provide control for custom builds, CI systems, and queries. During review, CodeQL is most useful as a consistent source of security findings and data-flow evidence, not as a substitute for human judgment or testing.

Learn more about the best automated code review tools and static application security testing.

Official source for “Scanning for security vulnerabilities with CodeQL”: https://www.awesomecodereviews.com/automation/codeql/. Last updated: July 24, 2026

Code Review Checklists

Sun, 29 Jan 2023 08:59:30 GMT

To learn more about using checklist during code reviews read the following articles:

Official source for “Code Review Checklists”: https://www.awesomecodereviews.com/checklists/. Last updated: February 22, 2023

Security code review checklist

Thu, 26 Jan 2023 22:40:32 GMT

Using a secure code review checklist helps you find security vulnerabilities systematically during code review, and is a code review best practice. With this security code review checklist, you know exactly which security flaws to look for and how to implement secure coding practices.

Table of Content:

Popular security vulnerabilities lists
Security vulnerabilities are often undetected
Find security vulnerabilities systematically
Secure code review checklist - Short version:
Secure code review checklist - Extended version
Practice finding security flaws during code reviews
Conclusion

Popular security vulnerabilities lists

You probably heard about the OWASP Top 10, or the CWE Top 25. OWASP Top 10 is a list of the ten most critical web application security risks, such as Injection Broken Authentication and Session Management, or Cross-Site Scripting (XSS). OWASP Top 10 are published and maintained by the OWASP (Open Web Application Security Project) community. Similarly, the CWE Top 25 is a list of the 25 most prevalent software weaknesses which the MITRE Corporation publishes and updates. In contrast to the OWASP Top 10 which focuses on web application security risks, the CWE Top 10 focuses on a broader range of software security vulnerabilities that also affect mobile and desktop applications.

Watch my video on finding security vulnerabilities and bugs that appeared on the OWASP DevSlop show to learn more about secure code reviewing.

Security vulnerabilities are often undetected

The problem is, even if you heard about both lists highlighting common security risks, and even if you studied the listed vulnerabilities, it’s unlikely you know them all by heart. As a result, during code reviews, many security vulnerabilities are overlooked by developers. Also, following the “shift left” mentality of testing and security, you do not want to wait for a dedicated security team to perform static application security testing, or to find many issues during dynamic application security testing.

A study about security aspects during code reviews confirms that developers often do not focus on security aspects during code reviews. Many developers that participated in the experiment did not find the seeded security bugs. When the researchers reminded the developers to explicitly inspect the code for security flaws, their ability to find security defects increased. Yet, the study made clear that developers still struggle with finding security issues during code reviews. The researchers state: “developers report the lack of training and security knowledge as the main challenges they face when checking for security issues.”

Find security vulnerabilities systematically

This is where secure code review checklists, also referred to as security checklists, come into play. Code review checklists are a wonderful learning and mentoring tool, and an important code review best practice. They also help you remember which issues you should focus on. Finally, with a secure code review checklist, you can inspect the code systematically for security vulnerabilities.

Reviewers using a code review checklist outperform reviewers who are not.

All three benefits of using a security-focused code review checklist help you adapt, practice and promote secure coding practices within your team. So, without further ado, let’s have a look at a secure coding checklist:

Secure code review checklist - Short version:

What security vulnerabilities is this code susceptible to?
Are authorization and authentication handled in the right way?
Is (user) input validated, sanitized, and escaped to prevent cross-site scripting or SQL injection?
Is sensitive data like user data, or credit card information securely handled and stored?
Does this code NOT reveal some secret information like keys, passwords, or usernames?
Is data retrieved from external APIs or libraries checked accordingly?
Does error handling or logging NOT expose the system to vulnerabilities?
Is the right encryption used?

Secure code review checklist - Extended version

Input Validation

Authentication and User Management

Are sessions handled correctly?
Do failure messages for invalid usernames or passwords NOT leak information?
Are invalid passwords NOT logged (which can leak sensitive password & user name combinations)?
Are the password requirements (lengths/complexity) appropriate?
Are invalid login attempts correctly handled with lockouts, and rate limits?
Does the “forgot password” routine NOT leak information, and is NOT vulnerable to spamming?
Are passwords NOT sent in plain text via email?
Are appropriate mechanisms such as hashing, salts, and encryption used for storing passwords and usernames?

Authorization

Are authentication and authorization the first logic executed for each request?
Are authorization checks granular (page and directory level)?
Is access to pages and data denied by default?
Is re-authenticate for requests that have side effects enforced?
Are there clear roles for authorization?
Can authorization NOT be circumvented by parameter or cookie manipulation?

Session Management

Encryption and Cryptography

Are state-of-the-art encryption algorithms used (such as FIPS-140)?
Are minimum key sizes supported?
What types of data must be encrypted?
Has sensitive data been secured in memory, storage and transit?
Do restricted areas require SSL?
Is sensitive information passed to/from non-SSL pages?

Exception Handling

Practice finding security flaws during code reviews

To practice finding security bugs during code reviews, I prepared a small codebase for you. The codebase is in HTML, and JavaScript and uses Express. As long as you have experience developing code, I recommend reviewing the code even if you are not familiar with JavaScript.
The example codebase is small, and you should be able to find quite a few of the seeded security defects and other problems within the code. Here, you find the repository to test your secure coding practice knowledge.

Conclusion

Research is very clear on the power of code review checklists. Code reviewers who use a code review checklist outperform code reviewers that don’t. So, I hope this checklist is helpful and valuable to you and that you start boosting your code review effectiveness with it.

You can find the security code review checklist also on GitHub. And, check-out my general code review checklist that helps you focus on the most important issues during code review. Also, read about other best practices for code reviews here.

Official source for “Security code review checklist”: https://www.awesomecodereviews.com/checklists/secure-code-review-checklist/. Last updated: January 26, 2023

30 Proven Code Review Best Practices

Tue, 17 Jan 2023 08:59:30 GMT

Which code review best practices do companies such as Microsoft, or Google follow to ensure great code review feedback? How do you stay productive while doing code reviews?
In this article, you learn 30 code review best practices for code reviewers and for code authors.

As this article is an in-depth resource, let me give you a quick overview of the 30 best practices for code review first.

Code Review Best Practices Overview

For code reviewers

Give respectful feedback
Talk in person
Document decisions
Explain your viewpoint
Make rejections exceptions
Do reviews daily
No context-switching
Give timely feedback
Consider time zones
Make it a team effort
Review often
Focus on core issues
Review tests first
Use checklists
Fight bias

The benefits of code reviews rise and fall with the value of the code review feedback. If done correctly, code reviews can help to ensure a high-quality code base. However, if teams are not aware of and do not follow best practices for code review, developers may experience several code review challenges. In the worst case, reviewing code can slow your team down.

I have been researching and working with teams at Microsoft for several years. Through several large scale-studies, we discovered several best practices that help teams during code review to stay productive and boost their code review value.

If you are new to code review, let’s look at a typical code review process in a nutshell, or read get a full picture in the code review 101 guide. You can also skip this introduction and jump directly to the first peer code review best practices.

A typical code review process

A typical tool-based code review process starts when the engineer prepares the code for review. Then, she selects relevant reviewers for the code change. The reviewers are notified. The reviewers then inspect the code for defects, readability, and maintainability and give feedback on the code. The code review author works on the feedback until all parties are satisfied. Then, the code is merged with the common code base.

A typical tool-based code review

To ensure that the code review process is smooth and does not become a nightmare, it is important to understand code review challenges and which code review best practices you can follow to overcome those.

The main code review challenges are:

not getting useful feedback,
not having enough time to do code reviews,
code reviews taking too long, causing long waiting times.

The code review best practices below help counteract those challenges by making the job of the reviewers as easy as possible. They also help the reviewer focus on providing valuable feedback.

Code review best practices for code authors

In a code review, there are two different stakeholders: the code author, who asks for feedback, and the code reviewers, who look through the code change and provide feedback. As a code review starts with the author, I explain the code review best practices for code authors first.

1. Read through the change carefully

The first code review best practice is to read carefully through the code change before submitting the code for review. There is nothing worse than asking several developers to look through the code and give feedback on issues you could have fixed yourself.

This wastes everyone’s time, and it might make you look bad. For future code reviews, developers may also be reluctant to review your code.

So, ensure you use a code review tool or a diff tool that can highlight what changed between this and the previous version. Because these tools show you the code differently and highlight the parts that changed, it makes it easier for you to review your code yourself before sending it out.

Often you will see changes that you forgot you made or missing issues highlighted you should fix before asking somebody to review. Remember, the best time to fix issues is before you send the code out for review.

Thoroughly look through your code before submitting for review

The best time to fix issues is before you send the code out for review. Click To Tweet

2. Aim for small, incremental changes

As a developer, you should always strive for small, incremental, and coherent changes. This code review best practice helps when working with code revision tools, such as git or SVN.

Small, incremental code changes are also a crucial code review best practice, as other developers must be able to understand your code change in a short amount of time.

10 lines of code = 10 issues.

500 lines of code = “looks fine.”

Code reviews.

— I Am Devloper (@iamdevloper) November 5, 2013

If several changes with different purposes happen within one code review, the task of code reviewing becomes more difficult. This also decreases the ability of code reviewers to spot problems with the code. In several studies, we see that the value of the code review feedback decreases with the size of the change under review.

You also want to make sure the changes are coherent. Rarely are code changes too small to be sent out. It happens, but not that often.

The quality and value of code review feedback decrease with the size of the change. Click To Tweet

3. Cluster related changes

Another code review best practice is to cluster related code changes. Imagine you plan to add some new functionality, fix a bug in another function, and refactor a class. Then, each of those changes should be a separate code review. This way, you ensure the purpose of the code change is clear to the reviewers. A clear purpose makes the reviewing job much easier and increases the feedback value.
In case you realize your code change grew too large, you can use a technique called stacked pull requests to split the pull request into several smaller ones.

4. Provide a code review description

One excellent investment of your time during code review is to write a description of what this code change is all about. With this note, you help the code reviewers to understand the purpose of the code change and also why you changed it. This code review best practice speeds up code review time, increases the quality and value of the feedback, and improves code review participation rates.

Code reviewing isn’t a puzzle. Help reviewers focus on key issues by describing the code change.

Code reviewing isn’t a puzzle. Help reviewers focus on key issues by describing the code change. Click To Tweet

Interestingly, in our studies, we observed that developers really appreciate code change descriptions. They wish that more people would write descriptions. Counterintuitively, we saw that the same developers that wished others would prepare code review descriptions did not always include descriptions themselves.

One reason for this is that when you write the code yourself, you are so involved with the code that you fall for the expert blind spot. This means you think the code change is self-explanatory. The fact is, it is not.

To ease the work of writing code review descriptions, you can use pull request templates to pre-populate the pull request description already with the information that is relevant to be provided.

And if you do not help the reviewers to understand the code, they cannot provide valuable feedback.

So, write the note, even if it just says: “Updated the API endpoint to comply with security regulations”.

How much easier did the job of reviewing the code just get with this note? Remember, code reviewing isn’t a puzzle.

Even if the code change seems trivial to you, add a description so reviewers know what to expect. Click To Tweet

5. Run tests before submitting a code review

Take the time to run tests for your code change. Testing isn’t only a best engineering practice, but it’s also a code review best practice. Because testing your code ensures that the code actually works before you ask for feedback.

In addition, it shows that you respect the time of the code reviewers. It is not only embarrassing to send out code that obviously (as the tests show) is not working as expected, but it also kills everyone’s productivity. So, run the tests first!

And don’t forget to write new tests or update existing ones so that you cover the added or changed functionality reasonably.

6. Automate as much as possible

As one of the main challenges of code reviews is taking too long, you better follow the code review best practices of automating as much as possible.

Use style checkers, syntax checkers, and other automated tools like static analysis tools to help improve the code. This way, you make sure that code reviewers concentrate on giving valuable feedback and do not need to use their time to comment on issues that can be found automatically.

Similarly, choosing a good code review tool, and familiarizing yourself with its features helps save time and document the code review process.

7. Skip unnecessary reviews

You read that right. You can skip code reviews. Yet, it depends on your organizational policies, but if they permit it, you might consider skipping code reviews for trivial changes.

But stop before heading out and telling your team you need no code reviews anymore. Skipping code reviews is only advisable for trivial changes that do not change the logic, such as commenting, formatting issues, renaming of local variables, or stylistic fixes.

Skipping unnecessary code reviews boosts your productivity. Click To Tweet

8. Do not select too many reviewers

You should select the right number of reviewers for your code change. If more than 4 people come to your mind who should review the code, I’d like you to stop right there. Because adding too many developers to code reviews does more harm than good. Also, this is a sign that your code change is too big.

The main problem with adding too many developers as reviewers is that each one of them feels less responsible for giving feedback. Another issue is that adding more people than necessary decreases your team’s productivity.

Some studies suggest the code review best practice of adding only two active reviewers. At Google, only one reviewer reviews 75% of all code changes.

For some code changes, you want additional experts, like security experts or developers from other teams, to look through the code. But, more often than not, two active reviewers are just fine.

Many code review tools allow notifying developers without making them mandatory reviewers. This ensures that they stay in the loop and are aware of what is happening but removes the obligation for them to comment on your code.

9. Clarify review expectations

Every person that is added to the code review should know what you expect of them. Should they look for defects?

Did you add them because they should familiarize themselves with the code base? Or, did you add a developer from another team that uses the functionality of the codebase and you want them to look specifically at the API?

Every time you add a person as a reviewer, you should know and communicate your motivation. This code review best practice ensures that reviewers focus on the right issues, and helps fight bystander apathy.

10. Add experienced reviewers to get insightful feedback

Another code review best practice is to add experienced reviewers. Studies have shown that the most insightful feedback comes from reviewers that have worked on the code you are going to change before. They are the ones that give the most insightful feedback.

How often a reviewer has already reviewed code influences the ability to give useful feedback. Similar, experienced and senior developers tend to give better code review feedback.

But, be mindful of the workload of senior engineers, as they tend to be added as reviewers a lot. In addition, adding only developers that know the code already creates knowledge silos and hinders knowledge dissemination.

Developers that changed or reviewed pieces of the code before give the most valuable code review feedback. Click To Tweet

11. Add inexperienced reviewers for knowledge transfer

One of the code review goals is training and learning, so do not forget to include junior developers. Junior developers might not find the most bugs during code reviews, yet, code reviews will help them ramp up and learn from the senior members of the team.

Also, do not forget to add people that are not familiar with the code base but that benefit from the knowledge to allow knowledge dissemination. Having several people on the team that are familiar with the codebase helps if developers go on vacation or even leave the company. But be strategic about it. Make a plan on how many people should cover and know about certain parts of the codebase, and then use code reviews to disseminate the knowledge.

12. Notify people that benefit from this review

For some people, like project managers or team leads, receiving notification about code reviews (without being required to do the code review) is beneficial. But, you have to make a conscious decision on whom you gonna notify. Not everybody cares or should care about your code review.

Notification fatigue is real. In addition, specify your expectations so that developers know if they are notified because they should review the code, or just to keep them in the loop. Some code review tools allow specifying roles explicitly.

Do not add everybody to the notification list. Only add people who benefit from the information that a code review is in the process.

I have seen teams where each team member was added to each of the code reviews of the extended team by default (+70 people). This practice is like adding nobody to the list. Or, in the worst case, you have several of your engineers spending their time looking through hundreds of code reviews to figure out if it’s relevant for them.

13. Give reviewers a heads-up before the review

An effective code review best practice is to let your co-workers know ahead of time that they will receive a code review soon. This code review best practice reduces turn-around times substantially.

So, let them know a code review is coming their way as soon as possible.

Giving people a heads-up that a code review is on its way can speed up review time. Click To Tweet

14. Be open to the suggested changes

Receiving unexpected comments or feedback might make you tense and defensive. Try to prepare yourself mentally and work on your ability to be open to suggestions and different viewpoints. Always start with the assumption that the reviewer had the best intention.

Don’t be defensive if confronted with unexpected feedback.

If some feedback made you uncomfortable, try to sort things out as soon as possible. Sometimes it is a good idea to have more personal face-to-face conversations to resolve some issues.

15. Show respect and gratitude to the reviewers

Code reviews rise and fall with the team’s feedback culture. As a code author, it is a code review best practice to show gratitude and value the received feedback. Make sure to carefully consider the reviewers’ feedback and communicate throughout the feedback cycle.

Tell the reviewers which actions you took and which decisions you made because of the received feedback in a respectful manner.

Code review rises and falls with the quality of the team’s feedback culture. Click To Tweet

But, creating a great feedback culture is a two-way street. Naturally, code reviewers influence the culture a lot. So let us look closely at this best practice for code reviewers.

Code Review Best Practices for Code Reviewers

Being asked to give feedback on a code review is an honor, so you want to make sure you know how to give valuable code review feedback.

During code reviews, you can not only demonstrate your skills and knowledge but also mentor other developers and contribute to the team’s success. Nothing worse than investing time in code reviews and not getting valuable feedback.

16. Give respectful and constructive feedback

Even though it reads like a no-brainer, code reviews do put the code author in a vulnerable position, so you must be considerate of that.
Your job is to give constructive and valuable feedback but also to do so in a respectful manner.

Especially when you use a code review tool and give feedback in a written form, please reflect on how and what kind of feedback you give. It is just so easy to hurt someone’s feelings – especially in written form. Too often, time pressure might make you give a sloppy answer that can be misinterpreted.

17. Talk in person if necessary

Code review tools and chat tools allow us to communicate with our peers asynchronously and effortlessly. But, there are quite a few situations where proper human interaction, either face-to-face or via voice/video, cannot be beaten.

Complex issues, for example, can be much more efficient and positively resolved once you hop over to your colleague or call her and discuss it personally. The same holds true for contentious issues or sensitive matters.

Maybe it is a better strategy to write a private email or seek a personal discussion with the code author if you think you might hurt some feelings are make the engineer lose the face. So, whenever you face a complex issue or might hurt some feelings, rethink your communication channels and act accordingly.

18. Document code review decisions

Even though less traceable conversations, such as face-to-face or video calls, can make a big difference in team dynamics, it is important to document the discussion. It is a best practice to record and track the code review outcome for future reference by using traceable tools such as the code review tool.

The code review tool is the right communication channel for all simple matters, as it allows the whole team to follow along and enables them to look up decisions and understand code development after the fact.

Even if you prefer to do code reviews synchronously, take the time to put a few notes in a code review tool to let also others (or your future self) know the outcome of a discussion.

Leaving traces about your decisions and changes helps to understand code evolvement

19. Explain your point of view

Let’s be honest; having your code criticized isn’t something the code author will enjoy. So, you must be thoughtful and explain your reservation in a polite, constructive, and friendly way.

Explaining the reasons behind your feedback and the suggested changes not only helps the code author to learn and grow but also helps the author to understand your viewpoint. It also promotes an ongoing dialog with the author.

Tell the code author exactly what she has to do to get the change accepted by you.

If you criticize a code change, explain precisely what you expect so that you approve the code review. Click To Tweet

20. Make code review rejections exceptions

Especially in a company and closed-source setting, code review rejections should be a very rare exception. It is a significant red flag if developers cannot produce code that will make it into the codebase. The ideas of rejection stem from the open-source setting. Here, it is normal for outside developers might suggest changes that do not align with the vision or roadmap of the open-source project as they are not involved. Also, because everyone is allowed to submit code, it frequently happens that the submitted code is not in an acceptable state or of quality.

Both should not happen in an environment where people work closely with each other. Here, developers should know the roadmap, and the tickets they work on should correspond with the vision. Also, after an onboarding period, even junior developers should be able to write code that passes the internal code quality standards – at least after some constructive code review feedback. If this is not the case, project management and the learning culture need to be revisited.

21. Integrate code review into your daily routine

Some of the biggest challenges during code reviews, for both the code author and the code reviewer, are time constraints.

As a reviewer, you might find it challenging to take time out of your day to review the code of your peers. But code reviews can be very beneficial to you and the team if done in the right way.

To ensure you stay productive, structure your day-to-day business in a way that you set dedicated time aside just for doing code reviews. For example, plan to work on code reviews every day from 11 to 12 AM.

This way, you make sure you can account for the time for code reviews and also make it an expected activity for you and your team. This schedule will come in handy every time you have a reflection on your work progress or an evaluation of your work.

22. Reduce context switching as it kills productivity

Switching from one task to another is costly. Knowing you do not stop whatever you do every time a code review comes along your way ensures you can work more focused.

Which time slots work depends on your workload, the number of code reviews you have to perform, as well as on the time those reviews normally come in. In some settings, your team benefits from two (shorter) scheduled reviewing times, such as in the morning and before you leave the office. This way, your peers do not have to wait for your feedback too long.

Context switching because of code reviews kills productivity

Context switching kills productivity. So have dedicated code review times. #codereview Click To Tweet

23. Give feedback timely

Do not jump right into a code review whenever the notifications pop up because of context-switching costs. Still, it has several advantages for you and the code author to review the code in a timely matter.

It is essential to give feedback as soon as possible. Also, Google recommends fast code reviews in Google’s code review best practice guideline. This ensures that you do not block the code author by having them wait for feedback. Also, if the author has to wait too long, it becomes harder for her or him to remember the changes and incorporate the feedback. Remember, long waiting times are a number one code review challenge.

Being one of the first reviewers (especially if there are quite a few) also ensures your effort in looking through the code actually adds value. If you are the fifth person inspecting the code, chances are you will not add new insights anymore. If that happens frequently, implement the code review best practice for selecting fewer reviewers.

24. Consider the time zones of your peers

Nothing is more frustrating than if a developer in another time zone reviews your code at the ‘wrong’ time. But what is the wrong time? If you have a big time zone difference, the wrong time to review a change is the time that stretches the time zone differences even more.

So, as a best practice for code reviews, when designing your personal code review schedule, check the time zones of your peers. It might make a big difference for someone if you dedicate half an hour in the morning instead of in the afternoon to do code reviews, while for yourself, it might not be that big of a deal.

25. Have your team play along

Code review is a team effort. If it’s only you that looks at reviews in time or systematically with checklists, you are not getting the complete benefits of code reviews. Instead, make sure everyone on the team knows the benefits, challenges, and code review best practices.

Especially for scheduling and coordination, there are effective habits that are easy to learn but help with accountability and workload balance. For example, the “give-one-take-one” practice.

The “give-one-take-one” practice means that every time you send out a code review, you do a code review for your colleagues. If you combine this with the code review best practice of sending out small code changes to review, the team’s workload will be balanced, and code reviews done in a timely manner.

26. Review often, not in a big-bang fashion

Research shows you give better code review feedback if you review often and, therefore, fewer changes at a time. That means that you do not wait until several code reviews pile up to look through them in one go. Instead, you stick to your schedule and review one code review (or even parts of one if it is a larger code review) at a time.

If code reviews are too large and take too long, you can suggest the code review best practices for small, incremental, and coherent changes to the code review authors. Another approach is to ask the code author to split the review into smaller changes, for example, using stacked pull requests.

Give better quality feedback to code reviews by not letting them pile up. Click To Tweet

27. Focus on core issues; do less nit-picking

Your goal as a reviewer should be to help with core issues, such as bugs, architectural problems, structural problems, or problems that will lead to maintainability issues.

Obviously, if you see typos, badly named variables, or styling issues, you might also point that out. Still, this is not your main task, and understandably, over-discussing minor issues isn’t valuable to code authors. So, follow the code review best practice to focus on core issues, and show when you nitpick (for example, with the appreciation NIT).

28. Start by reviewing test code first

While some developers would not even review test code, you follow the research in code reviews that suggests that starting your review with test code is a good idea. Also in the AI era, reviewing test code has gotten a completely different value. This is your safety net, and as we want to embrace the speed-ups GenAI can give us, we have to take even more care of our guardrails.

Also when you review test code first, you kill one bird with two stones. Test cases document the use cases of the code. Thus, they help you form a mental model of what this code is all about. This means you get a better understanding of the test code and can give more valuable feedback. In addition, it lets you focus on the test code itself. This way, you ensure your test code is also of high quality and covers the functionality in a reasonable way. Having a high-quality test code base is a great investment. It increases the maintainability of the code, decreases manual testing costs, and helps to reduce post-production defects.

29. Use code review checklists

Another code review best practice is to use a systematic approach for code reviews. A code review checklist can speed up and improve your code review performance. Instead of making one from scratch, download a ready-made list and customize it to fit your team’s practices and your needs.

Be sure to also look for a checklist that is tailored to your technology stack. You can also use checklists focusing on specific aspects such as accessibility or security not only to find problems with your code. In addition, code review checklists make for a great learning tool that helps you improve your skills. Having a code review checklist also builds a shared understanding within the team of what is important, and reduces conflicts, disagreements and prolonged discussions during code reviews.

To help you implement this practice, I reworked my code review checklist into a beautiful printable PDF version. This checklist is the highest-rated general code review checklist on GitHub, and today you can download it for FREE and make your code reviews more systematic.

30. Fight code review bias

Unfortunately, code reviews and especially judgments during code reviews can be clouded by bias. For example, a study at Google showed that developers that identify as women get more pushback during code reviews than peers that identify as men. Also, other studies look at how race, gender, ethnicity, and age influence the code review experience. And also, these studies find that pushback, code review rejections, and also the scrutiny with which reviews are performed are biased based on those factors. For example, a large-scale study on code review participation and acceptance rate in open source showed that code written by developers that appear to be black is more likely to be rejected than code written by developers who appear to be white. As such, make sure you are aware of the existing bias during code review and proactively take actions (such as reviews of reviews) to reduce bias, harassment, and prejudice in code reviews.

Summary of code review best practices

Now that you know 30 best practices for code reviews, I wonder how many of those you already implement in your team. Tell me your score, and also which code review best practices you haven’t adopted yet and why. You can find me on Twitter at twitter.com/mgreiler.

Official source for “30 Proven Code Review Best Practices”: https://www.michaelagreiler.com/code-review-best-practices/. Last updated: July 23, 2026

10 Best Code Review Tools In 2024

Tue, 17 Jan 2023 08:59:30 GMT

Let’s learn about the 10 best code review tools in 2024, and which features stand out for each of the code review tools. While following code review best practices make code reviews easier, choosing the right tool for the job is as important. By looking at the pros and cons of each tool, I, therefore, help you decide which code review tool is the best for you. Finally, I give you a glimpse into new and upcoming code review tools, that can nicely complement the review functionality of code review tools such as GitHub or GitLab.

Here is what awaits you.

10 Best Code Review Tools
1. GitHub
2. GitLab
3. Azure DevOps
4. Bitbucket
5. Crucible
6. CodeStream
7. Review Board
8. Gerrit
9. Jetbrains Space
10. Review Assistant
Other emerging code review tools
Frequently Asked Questions (FAQ) about code review tools

10 Best Code Review Tools

The list of code review tools is based on the popularity of the tools. In addition, I’ll highlight a few new code review tools that will change how we do code reviews today.

Other handy articles are my post about AI code review tools, and the one about best tools for static and dynamic analysis during code reviews.

1. GitHub

GitHub is a cloud-based repository hosting and management platform that allows developers to collaborate effectively.

It has a built-in code review tool that code authors use to seek feedback from reviewers. This allows a seamless review process within GitHub when developers introduce new changes to code.

GitHub’s code review tool lets developers initiate and respond to reviews in simple steps. After creating a pull request, the author assigns one or more reviewers. GitHub allows the author to describe the code changes and areas on which the reviewer should focus. Then, reviewers can comment, approve or request further changes from the author.

While GitHub lacks native automated code check features, it integrates with external ones to provide a more extensive review experience. For example, Datadog Static Code Analysis can report security and quality findings as inline pull-request comments and provide suggested fixes for supported rules.

GitHub also provides a code scanner, CodeQL, that helps developers identify vulnerabilities. Developers can also use GitHub Actions to enable CI/CD workflow and third-party integrations natively on GitHub. Recently, GitHub also added a new feature which enables required workflows to be run and passed during CI/CD. Alternatively, developers integrate external code scanners to set up a robust CI/CD pipeline that runs extensive tests and automatically merges the changes upon success.

Despite the attractive advantages, GitHub is not the best code review tool when working with large repositories. For example, GitHub strictly recommends keeping the size of a repository below 5GB, while Gerrit has no problem managing a 1TB repository. In such cases, Gerrit is the better option. GitHub also proved hard to navigate code reviews when comment threads are large, or when there are many or large files. The need of expanding and collapsing comments, as well as diff-views of files, is time-consuming and annoying and often leads to overlooking issues.

GitHub has a free plan for individual users, offering yearly teams subscription from $44 per user. GitHub is cloud-based but also deployable on-premise with GitHub Enterprise Server.

Github's Pros:

GitHub has a large, very lively marketplace and provides many add-ons to enhance code review.
It allows teams to set review policies, including setting permissions and automatically assigning reviewers from teammates.
Code review is a straightforward process in the GitHub environment.
It offers detailed oversight of changes in code files.
GitHub’s threaded comments allow teams to follow up and revisit past reviews easily.
It enables CI/CD workflow with GitHub Actions and vulnerability scans.

Github's Cons:

GitHub lacks stability when supporting review workflow involving large or multiple files and comments.
Reviews with many files, or large files also require the reviewer to collapse and expand files, complicating the review process.
It is limited to Git repositories.
Resolving merge conflicts using the web interface is tedious and error-prone.

2. GitLab

Like GitHub, GitLab is a Git-only repository platform that lets teams collaborate remotely, and also offers a built-in code review tool. It offers developers free private repositories, an attractive feature for those with security concerns about publicly-accessible ones. However, GitLab operates with very different principles and features than its major rival. GitLab prioritizes stability and is built around a comprehensive CI/CD pipeline, while GitHub focuses on speed.

When making code changes on GitLab, the platform creates separate stable branches beyond the master branch. This allows QA teams to run multi-step testing on the branches. Meanwhile, GitHub merges changes directly to the master branch while allowing developers to roll back the changes quickly.

GitLab also offers flexibility when setting up the code review requirements. You can specify the number of approvals needed for each request and determine qualified reviewers to grant such approvals. For example, you can prevent users who made commits from approving code reviews.

In 2021, GitLab introduced a new ‘Reviewers’ role alongside the existing ‘Assignees’ to better differentiate participant roles in the review stages. Assignees are developers directly accountable for the merging, while Reviewers are partially involved in the process. Now, GitLab allows you to submit merge requests directly from Visual Studio Code instead of switching to GitLab’s browser-based dashboard.

Thanks to its CI/CD-first orientation, you can run automated test scripts to reduce review time. Moreover, GitLab allows you to carry out various code analyses, including static application security testing (SAST), dynamic application security testing (DAST), and dependency tests. It also provides an extensive vulnerability report.

GitLab is an open-source platform that runs on the cloud but is also installable on on-premise servers. You can use GitLab free, with optional advanced features starting from $19/month.

GitLab’s Pros

GitLab has a powerful integrative CI/CD pipeline and supports vulnerability scans.
It is deployable on cloud and private servers, even without purchasing an enterprise plan.
GitLab allows teams to set flexible review policies with varying permissions for code owners and teammates.
GitLab’s private repositories ensure a more secure development workspace.
Some features that you need to install as third-party tooling on GitHub, are already build-in using GitLab.
It’s available as an extension for Visual Studio Code, allowing developers to not only commit changes (which is also supported by GitHub), but also to review code within the IDE.

GitLab’s Cons

Premium subscriptions are expensive.
Integration with 3rd party tools can be complicated.

3. Azure DevOps

Azure DevOps is a web-based CI/CD pipeline offering versatile and disciplined code review practices. While Azure DevOps’ workflow resembles those of GitHub and GitLab, it allows developers to be more rigorous when reviewing codes. For example, you can set branch policies to specify minimum reviewers for each request. This differs from GitHub, where you configure code review settings on the team’s level.

With Azure DevOps, developers can make linked work items or comment resolutions as part of the approval prerequisites. This allows them to ensure each approval is supported by related user stories, product backlog items or issues for traceability.

Before using the code reviewer, you must define each participant’s roles, security level and permissions. Learning to enable or disable certain policies might be tricky for new Azure DevOps users. But once it’s done, commenting and tagging reviewers in feedback is straightforward.

Being a comprehensive CI/CD solution, Azure DevOps provides vast integrations with various apps in its marketplace. For example, developers can use Sonar Cloud or Ado Security Scanner for automated vulnerability analysis and code quality checks. Azure DevOps is also available as a plugin for IntelliJ IDEA, Eclipse, and Xcode, but the extension doesn’t support in-IDE code review. Likewise, users of Visual Studio and VS Code can connect to Azure DevOps services via an extension.

Azure DevOps is not an open-source project. It runs on the cloud but is deployable on private servers with Azure DevOps Server. Signing up for its Basic Plan is free for the first 5 users and costs $6 per user monthly after that.

Azure DevOps’ Pros

Decent options for integrations on the marketplace, including SonarCloud, Ado Security Scanner and Beagle Security.
Available on the public cloud and installable on private servers.
It supports diverse types of repositories, including Azure Repos Git, GitHub, BitBucket.
IDE extension allows developers to launch pull requests from IntelliJ IDE, Eclipse, Xcode, Visual Studio and VS Code
Allows developers to set up detailed and strict code review policies.

Azure DevOps’ Cons

Setting up is not straightforward.
It needs more integrations with 3rd party vendors.

4. Bitbucket

Also, Bitbucket offers a built-in code review tool that works very similarly to GitHub’s, GitLab’s and Azure DevOps’s code review tools.

It automatically integrates test results and security scans into the pull request view. It allows to specify code review policies with conditions, thus ensuring each pull request is inspected consistently. For example, Bitbucket allows you to enforce a minimum number of required reviewers, or that the build must pass without warnings.

Especially the UI differs from the other code review offerings of repository system platforms. While GitHub and GitLab make heavy use of tabs, Bitbucket prides itself to show all necessary information within one page.

Another nice feature Bitbucket’s code review tool offers is to create tasks out of code review comments. This is a good feature whenever code review reveals feedback that isn’t going to be worked on during this pull request but should be captured for later.

Bitbucket Pros

Great enterprise solution offering nice code review features
Integrates well with widely used tools such as Jira
Better code review UI for most use cases

Bitbucket Cons

Expensive
No free plan
Harder to review commit-based

5. Crucible

Crucible is one of the best Code review tools that support diverse types of code versioning systems. Besides Git, the web-based code reviewer integrates with BitBucket Server, Mercurial, CVS, Subversion and Perforce. It also works with other popular services, such as Jira, GitHub and BitBucket.

Crucible provides well-defined roles that assign developers as an author, a reviewer or a moderator, where each role has different or overlapping permissions in the code review tool workflow. What impresses me is Crucible’s reviewer selection feature, which suggests reviewers based on their contributions to the code files.

The commenting workflow is quite different than in the previously discussed tools. Crucible, for example, also allows reviewers to flag a comment as a defect, or to require changes. Further, comments can be added as drafts, which is helpful in order to give the reviewer the ability to reflect on their feedback, or to make changes to the comments as they learn more about the code that they are reviewing.

However, Crucible lacks a strict rule-setting ability for enforcing strict approval requirements. With Crucible, the author manually closes the review without stringent automated checks. Code authors use a separate add-on to grant approval after all mandatory reviewers review the changes. In this respect, GitLab, GitHub, and Azure DevOps are the better alternatives because of the preset rules.

As part of the Atlassian ecosystem, Crucible users can use apps in the marketplace to enhance the code review workflow. For example, enabling FishEye integration allows threaded changeset discussions amongst reviewers. Alternatively, you can use Crucible’s REST API to create a custom integration.

Despite its flexibility, Crucible’s drawback lies in its performance degradation when file revisions exceed 800 - which should hopefully never be the case. As a workaround, Crucible recommends that developers split the review into multiple ones to prevent data indexing issues.

Crucible is neither open source nor free. Built for private servers, Crucible charges a one-time payment that starts from $10 with up to 5 users.

Crucible’s Pros

Crucible supports different types of repositories.
It offers flexible integration options via the Atlassian marketplace or REST API.
You can create pre-commit reviews from IntelliJ IDEA by using the Atlassian IDE Connector.
It indicates how much time the reviewers took reviewing your codes.
Crucible’s inline discussion allows seamless conversations to take place on the source code.

Crucible’s Cons

It doesn’t offer free plans.
Crucible’s performance degrades when developers make substantial revisions.

6. CodeStream

CodeStream offers a different approach to code review. Unlike its more established competitors, CodeStream allows developers to request a review anytime from their IDEs without committing changes. This encourages discussions and problem-solving activities early on in coding.

Recently acquired by New Relic, CodeStream supports 11 popular IDEs, including VS Code, Visual Studio, and Jetbrains. It handles pull requests from GitHub, BitBucket and GitLab. CodeStream also integrates with other services, such as Jira, Slack and Pixie, to streamline code review with issue trackers and real-time messaging tools.

Once installed, CodeStream allows developers to raise a review request from any part of their code files with a sleek dialogue box. Reviewers then comment, approve or request changes from their IDE. They can also determine who is permitted to leave reviews.

While reviewing, reviewers can view the entire code tree and leave feedback on other parts of the source code. This is in vast contrast with the other tools that allow reviewers to only see code that has been changed. It’s also possible to start a discussion with CodeStream without launching a formal code review.

Another aspect that distinguishes CodeStream from its competitors is the way how it treats feedback. If a reviewer leaves a comment, this comment becomes a ‘codemark’, which will live on with the code. This way, the comments developers left about code are always visible within your IDE and are not bound to a certain code review.

CodeStream has yet to support code scanning or automated testing scripts. As a cloud-based code reviewer, CodeStream does not offer to be installed on-premise but compensates for this by enforcing cloud security with measures like encryption, VPN, and network packet filters. It uses commit IDs instead of transmitting source code across the network.

CodeStream has free, open-source extensions for VS Code, Visual Studio and JetBrains. It is also available without additional fees to New Relic subscribers.

CodeStream’s Pros

CodeStream allows discussion/review without leaving the IDE
It’s free.

It has a simple configuration for assigning reviewer permissions.
CodeStream applies robust security features, such as encrypting data on your machine and those stored on its server to create a secure code review environment.
Integration with issue trackers, observability, and communication tools.

CodeStream’s Cons

It is not deployable on private servers.
Lacks integrations for automated code testing and vulnerability scans.
The ability to implement certain code review policies is limited.

7. Review Board

Review Board is a standalone code review tool with hosting options. Developers can install the tool on local machines or subscribe to the cloud-based version. Either way, they get a review tool that supports almost every commonly-used repository. The list includes Azure DevOps, Bazaar, Cliosoft SOS, CVS, Git, HCL VersionVault, IBM Rational Clear Case, Mercurial, Perforce, and Subversion.

With Review Board, developers can ask for reviews without opening a pull request. Code authors publish review requests, which alert the assigned reviewers on their dashboard. The reviewers scroll through the review summaries and access those code reviews that require their feedback. Once resolved, the author commits the changes to the repository.

The tool’s workflow is quite standard, but you can augment it with available automation tools. Review Board allows integration with static analysis tools, style checkers and CI/CD platforms. It also enables streamlining the review workflow with Slack, Asana, Jenkin, Trello and other services.

Review Board appeals with its bright colored panels, well-spaced text and CLI for advanced programmers. Yet, its UI has a touch of an “old-school-open-source” system.

Another nice feature of Review Board is that it allows reviewing not only code, but also PDFs, documentation, and graphics, all in one place.

It’s free and open-source, but the hosting option starts at $29 per month.

Review Board’s Pros

Review Board supports automated code review and CI integration.
A free version is available.
Review Bots allow developers to run partially automated code reviews.
It shows diff views along the review requests in a simple interface.
Supports 3rd party integrations.

Review Board’s Cons

It does not integrate with any IDE.
Diff might not accurately display the changes when part of the code was moved.
UI looks old-school.

8. Gerrit

Gerrit is designed so that each commit represents a single, reviewable change. Instead of creating a branch from the main branch and reviewing multiple commits on this branch for each pull request, Gerrit enforces to review each commit separately. This fine-grained approach proves even viable for Android developers who use Gerrit to review the OS and manage thousands of daily commits. A natural consequence is also a small fine-grained review culture at companies such as Google, that use Gerrit for code review.

Like GitHub, Gerrit is exclusive for Git repositories. Gerrit acts like a Git Server and can be deployed on a public or private cloud. While it’s engineered for efficiency, Gerrit lacks the intuitive UI that GitHub does. Its dashboard features panels and controls that support a functional code review tool workflow.

To request code review, developers use the CLI to push code changes to Gerrit and the web interface to leave feedback. Gerrit allows reviewers to vote and approve the results instead of setting rigorous code review policies. By selecting from a score of -2 to +2, the reviewer indicates approval or request for further changes. Once approved, a human verifier validates the result. Then, the author merges the changes with the master branch.

Gerrit is free, open source and works with Eclipse-based IDEs and IntelliJ IDEA. Besides being a robust code reviewer, it also integrates with plugins to provide analytics, event listeners, issue tracking and other useful functions. Furthermore, Gerrit has a REST-like API that enables customized automation.

Gerrit’s Pros

Gerrit is free.
It can be hosted on public and private clouds.
Available as plugins and enable commenting in Eclipse and IntelliJ IDEA.
Ideal for projects with large repositories.
Gerrit has a simple voting system to approve or reject code changes.

Gerrit’s Cons

Gerrit is not as intuitive as other code review tools.
Lacks integration opinion with 3rd party services.

9. Jetbrains Space

Jetbrains Space is a new, comprehensive CI/CD platform that supports frictionless software development. Its internal code review tool succeeds Upsource, a popular solution amongst Jetbrains users. Space deploys on Docker containers, making it an ideal code review tool for private and public clouds. It works with Git repositories created within the project or migrated from external sources.

Space allows developers to start a review request on any JetBrains IDE, including IntelliJ IDEA, PhyCharm, Fleet, or PhpStorm. Developers create merge requests, provide comments and approve changes without leaving the IDEs. With Space, developers can enforce stricter control when merging changes. They set merge request rules to ensure several conditions are met for approval through quality gates. For example, allowing merges only if a specific number of code owners approves the changes and all automated jobs are completed.

To address growing project complexities, Space introduced Safe Merge, creating a temporary commit branch. This allows code authors to implement and validate feedback before merging them with the main branch.

Space offers various automation tools, issue trackers and other project management features to streamline code review. It also integrates with popular third-party collaboration apps. Space’s chat-like review conversations allow developers to track and manage changes easily.

Space’s mobile app further differentiates itself from competitors by enabling responsive code reviews on the go. Signing up is free and premium plans start from $8 per user monthly.

Space’s Pros

Space offers intuitive features with a modern interface.
Allows the review code on a mobile device.
It has extensive built-in automation services and 3rd-party integrations.
Works with all Jetbrains IDE, allowing developers to review codes in the editor.
Deployable on cloud and on-premise servers.
It offers an intuitive user interface that lets teams manage code changes and review efficiently.

Space’s Cons

Space’s premium plan is relatively expensive.
Extensive features might be overwhelming for new users.

10. Review Assistant plug-in Visual Studio

Review Assistant from Devart Software is a code review plugin for Visual Studio and is also available as a standalone tool. By installing the plugin, developers can request code reviews without leaving the editor. It supports a rather extensive range of version control systems, including Team Foundation Server (TFS), Azure DevOps, Subversion (SVN), Git, Mercurial (Hg), and Perforce.

Whether you’re practicing rigid or flexible code review workflow, Review Assistant allows you to configure the rules accordingly. In stricter reviews, you can appoint a moderator to coordinate the discussions. Meanwhile, code authors can request a review without specifying the reviewers in more lenient environments. This allows any team members to contribute to the conversations, which appeals to Agile teams.

While Review Assistant offers a coordinated review workflow, it’s also possible to start a discussion by commenting on any part of the code files. The plugin captures all review activities and makes them available in reports. Despite its flexibility, Review Assistant has limited integration, with MSBuild and Jenkins making up the few options.

Review Assistant is free for up to 3 users. Then, teams pay $349.95 per year for up to 10 users.

Review Assistant’s Pros

The plugin allows flexible code review, enabling teams to work without conventional restrictions.
Code authors can complete the review cycle without leaving Visual Studio IDE.
Review Assistant is available as a standalone code review tool.
It supports various version control systems.
Threaded comments allow developers to start a discussion or comment on any part of the code.

Review Assistant’s Cons

It has limited automation options.
Developers can’t reorder or filter the comments.
The integration only works with Visual Studio.

Other emerging code review tools

What the diff code review tool adds code review description

As software development practices evolve, more tools enter the marketplace to optimize code review processes. Especially noteworthy are the AI-powered code review tools that came to life through the breakthrough of large language models, and that promise to review our code without human intervention. Other interesting and very powerful code review tools are based on static and dynamic analysis of our codebase. You can find an in-depth article about tools to automate your code reviews here.

To round up this article, I want to highlight some cutting-edge, and even some experimental code review tools, that I think you should have at least heard of:

Reviewpad: This code review tool is your code review management assistant: it surfaces important information about your PR, like size, risk-profile and contributor, and helps drive the review process based on these characteristics.
WhatTheDiff: This is like ChatGPT, but for your code reviews. An AI-powered tool to automatically analyze and describe changes in pull requests. A must-have to make the code review best practice of good code review description a reality.
Plz.review: This code review tool aims to better GitHub’s review comment experience. For example, it allows reviewers to comment freely on other parts of the diff. It also allows for stacked pull requests.
GitHub Copilot: This is not exactly a code reviewer but an AI assistant that predicts and helps developers write codes. It’s your AI pair programmer, yet it also explains code, which makes it a great code review assistant.
AWS CodeGuru: AWS’s code reviewer uses machine learning to identify vulnerabilities and provides code quality recommendations.
Reviewable.io: This tool allows programmers to create discussion-like reviews on GitHub and GitHub Enterprise environments.
Softagram: Developers use Softagram to visualize and forecast the impact of code changes.

You still do not have enough? Have a look at my GitHub repository, where I keep track of code review tools.

Frequently Asked Questions (FAQ) about code review tools

When you learn about code review tools, you might have some additional questions, like why should you do code reviews, or how to choose the right tool. Let’s clarify your questions:

Why is code review important?

Code review allows software developers to identify bugs, vulnerabilities and bad coding practices that can’t be picked up by compiler and build tools. When left unchecked, such bad source code often manifest itself in production.

By practicing code review, you receive timely feedback from your team members on issues that escape your attention. This is helpful because we, software developers, might be blindsided in certain coding stages despite our best efforts. Read more about code reviews in this code review 101 article, or check out the 10 best code review techniques to review code more effectively and efficiently.

Why should you use a code review tool?

In a nutshell, code review feedback helps you identify code issues and improve software quality. Yet, without proper code review tooling, bottlenecks such as manual note-taking and email exchanges limit the process. As a result, software developers found themselves overwhelmed by non-coordinated feedback and costly delays.

Luckily, today, developers have access to modern review tools that allow them to spend less time seeking reviews and leaving constructive feedback. Instead of exchanging dozens of emails, code review tools ensure the entire code review process is transparent, well-coordinated and observable. That way, you can spare more time working on new features instead of manually sending and tracking unresolved review requests.

The code review tools presented in this post are a great way to ensure code reviews are done systematically. They allow for reviews to take place asynchronously. Feedback and changes are documented and can be traced, tracked and saved so that you can always come back to see why certain changes have been implemented or what your thought process or decision was at that time.

How to choose a code review tool?

Which code review tool is the best for your team depends on your requirements.

Teams that prioritize CI/CD automation might opt for GitLab or Jetbrains Space, which are built with integrations in mind. Meanwhile, CodeStream and Review Assistant allow you to request feedback from your teammates without leaving the IDE.

Version control systems that the tool supports are equally important. For example, GitHub and GitLab work exclusively with Git repositories. If you manage code with SVN, you need tools like Crucible or Review Board.

Some developers prefer cloud-based code review solutions that allow them to leave comments remotely. Others require tools that can be deployed on private servers.

Code scanners and automated testing are desirable features to prevent code exploits. Tools like GitLab and Azure Devop provide vulnerability scanners to help address security issues early on.

Finally, more and more people write and develop code while they are on the go. While online solutions such as GitHub and GitLab allow one to view the repository and even to leave comments in a mobile browser, the experience is far from good. Space, on the other hand, has a dedicated mobile code review app that makes reviewing on the go easy.

AI-powered code review tools

The tools discussed in this article focus on streamlining the code review lifecycle and process. This means they focus on allowing you to give comments, reply to comments, and accept or reject the code changes.

Other great code review tools help you, particularly, with doing the code review. I wrote about them in two articles: one highlighting AI-based code review tools, which use large language models to give “automagically” feedback about your code, and another post that lists static and dynamic analysis tools that also help you find and fix problems automatically.

Official source for “10 Best Code Review Tools In 2024”: https://www.awesomecodereviews.com/tools/best-code-review-tools/. Last updated: October 17, 2024

Code Review 101

Tue, 17 Jan 2023 08:59:30 GMT

Learn what a code review is, how to do code reviews and the common steps of a code review workflow, in this article from awesomecodereviews.com.

Here is what you will learn:

What is code review
Common steps of a code review
Making code review decisions
Code Review tools
Conclusion
Relevant research

What is code review

During a code review, developers inspect source code to improve the code or to learn about it. Code review is a valuable practice in software development because it helps to improve code quality, enhances teamwork and collaboration, promotes learning and helps to share knowledge. How exactly a code review process looks differs from company to company, and often even from team to team.

Code reviews can be very formal, following strict code review checklists, similar to a Fagan inspection. Yet, they can also be very informal, where, for example, one developer asks another developer to quickly look over the code while they pass by in the office. This form of code review is often referred to as “over-the-shoulder code review”. Code reviews can be done synchronously or asynchronously.

Nowadays, developers often use a tool to conduct code reviews. It’s also common that code reviews are done whenever a small work unit is ready (e.g., on a daily or weekly basis), and that code reviews concentrate only on newly developed or changed code. Yet, some companies still perform code reviews only after major milestones have been reached, and then they review large parts of the codebase.

You see, there are many nuances to code review practices and workflows.

Common steps of a code review

Independent of the differences in the code review processes, let’s look at which common steps code reviews have to get a better understanding of how code reviews take place.

In a nutshell, a code review will follow the following six steps:

Identify the code to be reviewed
Prepare the code for change
Select the reviewers
Conduct the code review
Discuss and address problems
Approve or reject the code

While those six steps give you a basic mental model of a code review workflow, there are several nuances to how development teams do code reviews. Let’s look at the different steps to code reviews more closely.

Identify the code to be reviewed

First, we have to identify which code needs to be reviewed. Often this could be a new feature or module, or it could be a change to existing code. If we look ten years back, development teams would review large parts of a codebase or even a whole codebase during a code review. And such code reviews would happen every few months.

Nowadays, it’s more common that the code that’s reviewed is related to a ticket or work item a developer has been working on. This means code reviews happen much more frequently (daily or weekly), and that way less code is reviewed.

In addition, during code reviews, reviewers will nowadays only focus on code that has been touched while a developer made changes. This means reviewers look only at lines added, deleted or changed, but do not inspect the code that has not been touched. The reason for this focus stems from the code review tooling used. The code review tools often only highlight the differences between one version of the code and the other version of the code.

Prepare the code for review

Before you ask another person for a code review, you should ensure that the code is of high quality and ready for review. This starts with a self-review. A self-review is the process in which you take the time to look through your code change carefully as if you were a reviewer. The best approach is to use a code review tool or any tool that highlights the exact changes that you made (i.e. a file comparison tool, also called a diff tool). This ensures that you see the code differently, and also helps you remember what changes you have made. During this inspection, clean up the code, add comments or documentation, and make sure that the code is organized and easy to understand.

You might also want to reorganize or better name your commit messages, as they can help the reviewer to better understand your work.

After the review, you ensure that the code compiles without warnings or errors. The code should be covered by relevant tests, that have been run and passed.

It is a good code review practice to also run static analysis tools such as linters over your code and fix any errors or warnings that the tool detects before asking a human code reviewer to spend time inspecting your code.

Select the reviewer

The next step is to select the reviewer or reviewers. Reviewer selection is a very important aspect of code reviews. The review is only as good as the reviewers you selected. This means, if you chose a person that knows little about the codebase, the programming language used, or the requirements this change implements, you cannot expect them to be very helpful to improve the code. Yet, adding them might help them to learn, which is also a code review goal.

In general, appropriate reviewers are people from your own or another development team or someone with specific expertise or knowledge related to the code being reviewed. Studies recommend choosing two reviewers. But it’s not uncommon to see only 1 or up to 10 reviewers selected per code review. There are also quite a few code review tools that help during reviewer selection.

When we talk about code review, we expect that the code author and the code reviewer are not the same people. Yet, exceptionally some developers will review their own code and call it a code review. Yet, we call the activity where at least one other person than the author looks at the code, a code review, and we will refer to the activity of inspecting your own code as a self-review.

Conduct the review

The actual code review can be conducted in a variety of ways, such as in person, via email, or using a code review tool. Independent of the tooling or meeting type, during the review, the reviewer carefully inspects the code, looking for defects, problems, and opportunities for improvement.

While historically, code inspections followed a rigorous review protocol, code reviews are nowadays very ad hoc in nature. This means, reviewers seldom get instructions on how to review the code or what to look for. This uncertainty and lack of focus reduce the effectiveness of code reviews. There are common aspects code reviewers are implicitly expected to look for, such as maintainability, readability, quality and correctness of the code. Code review checklists can be very helpful to make sure reviewers focus on all important aspects and do not forget some. They also make the code review process more systematic. Finally, code review checklists are a great learning tool and help teams have more coherent code reviews, in which the quality of the code review fluctuates less with the reviewer.

Discuss and address any issues

If the reviewers find issues with the code, they discuss those with the developer. Together, the code author and the reviewer come up with solutions to the problems. This means that they either agree to make changes to the code, or they decide that changes are not necessary. Often, comments of the reviewers are also questions about the code, that do not require any changes but help the reviewer to learn about the code or approaches.

During tool-assisted code reviews, those discussions take place in written form. Written communication can easily lead to misunderstandings, as people lack facial expressions, tone or body language to understand what the other person meant. Therefore, written code review feedback needs to be carefully phrased.

While unfortunately few developers ever get training on how to give and receive feedback, there is much that can be learned. Feedback can quickly hurt feelings, or even destroy relationships. Code reviews are also known to amplify biases, and studies show that depending on age, ethnicity, or gender, developers get more or less pushback during code reviews.

Also, during code review discussions conflicts can arise, which need to be handled and managed. To make sure code review discussions are productive and do not cross boundaries, it’s important that developers are aware of conflict management strategies, and possess conflict competence. In addition, code review guidelines, as well as a code of conduct should be in place.

With the right learning and feedback culture, teams can greatly benefit from each other during code reviews, and relationships are strengthened.

Approval or Rejection

The goal of the feedback loop, in which identified issues are discussed and reworked, is to get the code into a state that is acceptable and can be approved and merged with the production codebase. Some code review tools offer the functionality to reject the change. This means the code will not be merged with the codebase. Yet, rejections of code should happen on as exceptions.

A better approach than straight-out rejecting the code is to say the code is not acceptable in its current state. Yet, after some rework and another code review round at least parts of this code change will land in production. This often happens when the code change is large, and there are many issues that need to be addressed and reworked. During this rework, often pull requests are closed without being merged. Yet, the code appears again in a new pull request.

Especially in open source, code changes are indeed rejected with the consequence that the code never makes it into the codebase. This can happen if there are too many issues and the open source maintainers would need to spend too much time giving guidance or improving the change. Another common reason for rejection is that the proposed code change implements a feature that’s not aligned with the roadmap of the product.

In company or closed source settings, rejections that lead to never merging the code should be an absolute exception and a red flag that shows that something is wrong with the collaboration or project management. Rejections during code review decrease developer experience.

Making code review decisions

But how are code review outcomes determined? There are different strategies to approve code. They differ mainly by who decides whether the code change should be accepted or changes be made to the proposed solution.

In some teams, there is only one person, such as the team lead, the engineering manager or an architect that makes the “Yay” or “Nay” decision. Such decision approaches tend to be faster, yet can make developers feel less ownership of the product.

In other companies, more collaborative decision-making processes are preferred. Here, for example, the majority of the team decides what happens to the code. Yet, in practice, often there is no clear or explicit decision-making process or criteria.

Missing group decision strategies during code reviews can lead to a slowdown of the software development process, and developers often build up resentment of code reviews.

Code review tools

Code review tools assist during code reviews by allowing reviews to be done asynchronously, highlighting the differences between one version of the code and another, allowing developers to attach feedback in form of comments to the code, and by tracing and tracking discussions and decisions.

The most well-known and widely used code review tools are GitHub, GitLab, and BitBucket. All of those code review tools are integrated with the code repository, which makes them convenient to use, as no other tools need to be installed.

There are also standalone tools that are popular such as Gerrit and ReviewBoard that work with a broader range of version control systems such as SVN, or Mercurial.

Finally, many code review extensions let you review code right within your IDE.

A new and upcoming code review tool in this category is CodeStream. But most code editors such as Visual Studio, VIM etc. have their own plugins and extensions that allow you to review code.

Each tool has its own pros and cons, yet they all support discussing code during code reviews in a similar form.

Conclusion

As you have seen there are many nuances to how code reviews are conducted at different companies or in different teams.

Many of the approaches, such as synchronous or asynchronous reviews, have their pros and cons, which I’ll cover in an upcoming article.

By following a structured process during code reviews and using the right tools and techniques, developers can ensure that their code meets the highest standards and is ready for production.

As a good next step, learn more about code review best practices or look at the pros and cons of different code review tools.

Relevant research

Official source for “Code Review 101”: https://www.awesomecodereviews.com/fundamentals/code-review-101/. Last updated: January 17, 2023

A Code Review Checklist – Focus on these 10 Important Topics

Fri, 06 Jan 2023 22:40:32 GMT

A code review checklist, together with clear review guidelines, helps a team inspect changes systematically and keep its attention on high-impact risks.

The research is promising, but more nuanced than “checklists always win.” In a controlled experiment with 70 developers, a checklist was associated with better review effectiveness and efficiency on one complex task, while a guided checklist performed better on a smaller task. The researchers caution that the participants’ generally low review performance limits the strength of the results. Treat a checklist as a focusing aid, not a guarantee that a review is complete.

You can find the checklist I use in my code review workshops also in a compact format on GitHub. Let’s start with a quick overview of the code review checklist topics.

Code Review Checklist Overview

Implementation
Logic Errors and Bugs
Error Handling and Logging
Usability and Accessibility
Ethics and Morality
Testing and Testability
Dependencies
Security and Data Privacy
Performance
Readability

Code Review Checklist for Code Authors

Code review checklists are not only something for the code reviewers. Instead, as the author of the code change, follow the code review best practice and be your own reviewer!

So, before sending out the code for review, make sure that:

The code builds and passes the required static-analysis checks
The code passes the relevant unit, integration, and system tests
You have double-checked for spelling mistakes
You cleaned up temporary comments, debugging code, and outdated TODOs
You described what changed, why it changed, and how you verified it
You understand and can explain every part of the change, including any AI-generated code

Apart from that, you, as the code author, should run through the same code review checklist as the reviewer.

Code Review Checklist for Code Reviewers

As a code reviewer, it is your task to look for the most important issues first. It is easy to get hung up on nitpicking, but that is rarely the most valuable use of review time.

In one of our large studies at Microsoft, we investigated what valuable code review feedback looks like. We saw that comments revealing larger structural or logical problems are perceived as much more valuable than comments that focus on minor issues.

This is where code review checklists come into play. A great checklist directs your attention to the important and most valuable issues. Below you will find the checklist that I also use during my code review workshops. It is divided into ten sections, each with questions that guide your attention. First, let’s look at what AI-assisted development changes.

What Changes When Code or Reviews Are AI-Assisted?

The ten review topics do not fundamentally change when a coding agent or large language model (LLM) writes the code. The quality bar and the author’s responsibility remain the same. What changes are some of the failure modes:

Verify generated API calls, package names, versions, and behavior against authoritative documentation or the package registry. A 2025 USENIX study of package hallucinations in 576,000 generated code samples found nonexistent package references in output from commercial and open-source models.
Make sure generated tests assert the required behavior rather than merely repeat the implementation’s assumptions. A useful test should fail when the production change is absent or broken.
Check AI-generated pull request summaries against the actual diff, requirements, and design decisions.
Treat AI review comments and proposed fixes as hypotheses to verify, not as approval. The 2026 SWR-Bench study of 1,000 real-world pull requests found substantial room for improvement in current automated review systems. Aggregating independent review passes improved F1 scores by up to 43.67%, but it did not make human judgment optional.
Follow your organization’s data-handling rules before sending source code, prompts, logs, secrets, or personal data to an external AI service.

An AI reviewer can be useful for self-review or a focused additional pass. It should supplement the checklist, automated checks, and accountable human review. For practical tool and workflow guidance, see the overview of AI code review tools.

Implementation

Does this code change do what it is supposed to do?
Can the solution be simplified?
Does this change add unwanted compile-time or run-time dependencies?
Is a framework, API, library, or service used that should not be used?
Could an additional framework, API, library, or service improve the solution?
Is the code at the right abstraction level?
Is the code modular enough?
Can a better solution be found in terms of maintainability, readability, performance, or security?
Does similar functionality already exist in the codebase? If yes, why isn’t it reused?
Are there any best practices, design patterns, or language-specific patterns that could substantially improve this code?
Where relevant, does the code follow the project’s established design principles and language idioms?

Logic Errors and Bugs

Can you think of any use case in which the code does not behave as intended?
Could boundary values, missing or invalid input, concurrency, retries, timeouts, or partial failures break the code?

Error Handling and Logging

Is error handling done the correct way?
Should any logging or debugging information be added or removed?
Are error messages user-friendly?
Are there enough log events, and are they written in a way that allows for easy debugging?
Do logs and error messages avoid exposing secrets or unnecessary personal data?

Usability and Accessibility

Is the proposed solution well-designed from a usability perspective?
Is the API well documented?
Is the proposed solution (UI) accessible?
Is the API/UI intuitive to use?

Ethics and Morality

Does this change make use of user data in a way that might raise privacy concerns?
Does the change exploit behavioral patterns or human weaknesses?
Might the code, or what it enables, lead to mental or physical harm for some users?
If the code changes how people interact, are appropriate measures in place to prevent, limit, and report harassment or abuse?
Could the change unfairly exclude or disadvantage any group of users?
If the change uses an algorithm, AI, or machine learning, were its outcomes evaluated for harmful bias across relevant user groups, for example gender/racial/political/religious/ableist bias?

Testing and Testability

Is the code testable?
Have automated tests been added, or have related ones been updated to cover the change in functionality?
Do the existing tests reasonably cover the code change (unit/integration/system tests)?
Are there some test cases, input, or edge cases that should be tested in addition?
Do new or changed tests fail when the implementation is absent or intentionally broken?
For probabilistic or LLM-powered behavior, do evaluations cover representative and adversarial cases, including failure and fallback paths?

Dependencies

Are new or updated dependencies necessary?
Are package names, publishers, sources, and versions correct and supported?
Were lockfiles updated, and were known vulnerabilities and license constraints checked?
Were updates to documentation, configuration, or README files made as required by this change?
Are there any potential impacts on other parts of the system, public APIs, data formats, or backward compatibility?

Security and Data Privacy

Does the code introduce any security vulnerabilities?
Are authorization and authentication handled correctly?
Is untrusted input validated and handled with context-appropriate defenses, such as parameterized queries and output encoding to prevent security attacks such as cross-site scripting or SQL injection?
Is sensitive data minimized and securely collected, transmitted, logged, stored, and deleted?
Does this code change reveal secrets such as API keys, tokens, passwords, or other credentials?
Are responses from external services, files, webhooks, and model outputs treated as untrusted input?
If the product uses an LLM, could prompt injection expose data or trigger tools and actions without the correct authorization?

For more guidance during reviewing code for security vulnerabilities, check out this secure code review checklist.

Performance

Do you think this code change decreases system performance?
Do you see any significant opportunity to reduce latency, memory, compute, network, or model usage and cost?

Readability

Is the code easy to understand?
Which parts were confusing to you and why?
Can the readability of the code be improved by smaller methods?
Can the readability of the code be improved by different function, method, or variable names?
Is the code located in the right file/folder/package?
Do you think certain methods should be restructured to have a more intuitive control flow?
Is the data flow understandable?
Are there redundant or outdated comments?
Could some comments convey the message better?
Would more comments make the code more understandable?
Could some comments be removed by making the code itself more readable?
Is there any commented-out code?

Expert Opinions

In addition to the 10 topics on this code review checklist, think about whether someone else should have a look at this code.

Ask yourself:

Do you think a specific expert, like a security expert or a usability expert, should look over the code before it can be accepted?
Will this code change impact different teams, and should they review the change as well?

Well, that’s it. You looked and thought about the most pressing issues with this code review checklist. Congratulations!

Now, one of the exercises that I do in my code review workshops is to reflect with the participants on this checklist for code reviews by answering three questions:

Which parts of the code review checklist are you focusing on the most?
Which parts of the code review checklist do you tend to neglect?
Do you believe some of those points are more important for a checklist for code inspection? Why?

But what about coding styles and conventions?

Maybe during this exercise, you realized that I did not check whether the code follows the right coding style. So, is that not important?

Short answer: it is important. A clear coding style guide helps teams keep a codebase consistent. Consistency can make reviews faster, help people move between projects, and keep the code readable and maintainable. For example, Google has one of the fasted code review turnaround times specifically because of those clear and consistent rules.

Google, for example, publishes ready-made style guides for many languages. They are a useful starting point, but adapt a guide to the needs of your codebase and team.

Document the ground rules and automate the objective ones. Revisit them when the team’s needs change, but do not relitigate established style preferences in every review. This article explains how to get a team to agree on a coding standard.

Automate what can be automated

But, once you decide how your codebase should look, take the time to install and configure tooling properly so that code formatting becomes a matter of pressing a button.

Also, there is much more you can do. Use static analysis tools, such as Datadog Static Code Analysis or CodeQL to free up the time of your human code reviewers. Depending on their rules and configuration, these tools can enforce style, flag defect patterns, and detect classes of security vulnerabilities. It is worth the initial effort. Similarly, AI code review tools can help you with a first pass of the code review, but they are not a replacement for human judgment.

Be respectful, humble, and kind

Finally, the quality of the code review feedback does not only depend on WHAT you are saying but also on HOW you are saying it. So, the best code review feedback is worth nothing when it isn’t carefully phrased, humble, and kind.

For starters, phrase non-blocking feedback as suggestions instead of demands. For example, instead of writing “Variable name should be removeObject,” say, “What about calling the variable removeObject?” For more input, read my article on how to give respectful code review feedback.

Print out this code review checklist

As you need this code review checklist always next to you, I prepared a beautiful printable version for you. You can download the code review checklist as a printable PDF for free here. Alternatively, check it out on GitHub, and don’t forget to star it. Another resource that might be super valuable for you is my code review e-book.

Official source for “A Code Review Checklist – Focus on these 10 Important Topics”: https://www.michaelagreiler.com/code-review-checklist-2/. Last updated: July 24, 2026

Why we need an Awesome Code Review Workshop

Sun, 11 Sep 2022 08:00:57 GMT

Copy and Paste this email and send it to your manager to ask for workshop approval.

Dear manager,

Code reviews are an extremely effective collaboration and quality assurance technique. As you know, they help with knowledge transfer, improve the code base, prevent accidents, detect bugs, help us to stay informed about what colleagues are doing, and help us trace and track decisions for later reference.

Software developers are expected to know how to do code reviews without ever getting any formal training for it. Yet, code reviews are a socio-technical engineering practices that is performed on a team level.

This means that code reviews also require social, technical and organizational skills. This is also the reason why many teams struggle with it. In fact, research shows that the majority of engineering teams that practice code reviews experience major problems like:

a slowed-down development process
long code review turnaround times
large reviews that are hard to understand
bottlenecks and review overload
reviews that are just signed off without a review (aka rubberstamp reviews)
nit-picking or meaningless feedback
unfair reviews
conflicts

While we are taking our code reviews seriously, we also experience problems, and we believe that a workshop focusing especially on overcoming code review pitfalls will help us to get a better developer experience.

The workshop is designed to enable us to get to fast and effective reviews, which enables us to develop high-quality applications with fewer bugs!

That’s why we are asking for workshop tickets to https://www.awesomecodereviews.com.

Awesome code review workshops from Dr. Michaela Greiler are cohort-based training sessions that are interactive and focus on overcoming our main code review pain points. Dr. Greiler has been working with teams worldwide for over 10 years to improve their code review practice. She has worked with teams at Microsoft, Wix, NationalInstruments, and many more.

Did you know that developers spend between 10-20 percent of their time doing code reviews? We are no exception.

By participating in the workshop our team will be able to have a common understanding of how to do code reviews to gain the most benefits while minimizing their drawbacks. A faster and more effective code review process will literally save the company money, and the improved code quality will improve the user experience and allows us to react faster to user requests.

Dr. Greiler has taught hundreds of developers how to bring their code reviews from bottleneck to superpower.

We want to do this too!

Please support us in growing our skill set so that we can write better software for you and our users. Click here to visit Awesome Code Reviews and purchase the tickets for us: https://www.awesomecodereviews.com.

As code reviews are a team effort, I hope you will allow several of our developers to do the training. The good news is, Michaela offers group discounts. So the more tickets we purchase, the bigger the discount.

Please let me know if you have any questions. Thanks for helping us grow and learn. We are sure this will have a significant positive impact on our development practices!

Thanks!

- your team

This email is inspired by the awesome Kent C. Dodds, that has similar letters that let you ask for his Testing JavaScript and his EpicReact course. Thanks, Kent!

Official source for “Why we need an Awesome Code Review Workshop”: https://www.awesomecodereviews.com/workshop-approval/. Last updated: January 14, 2023

Use Pull Request Templates to Improve Code Review Descriptions

Wed, 24 Aug 2022 08:00:57 GMT

Learn how to use a pull request template to ensure code authors provide meaningful code review descriptions. Pull request templates help populate your pull request (PR) with the correct information, so code authors remember what’s important to explain about their PR. A good code review description significantly reduces the review burden for the code reviewer, and is a code review best practice.

Reducing the reviewer burden

If you have ever done a workshop or coaching session with me, you will know my mantra of “reducing the reviewer’s burden.” This means it’s essential for a great code review experience to make code reviewing as easy as possible for the reviewer. Today, I’ll show you how you can use code review templates or pull request templates to help the code reviewer to understand the pull request. In addition, pull request templates are a memory aid for the code author.

You have probably seen it before: a pull request with several files changed and only the sparse PR title. Maybe the description consists of strangely worded commit messages, which will not help you understand what is going on in this pull request.

Why does this happen? Why didn’t the code author take the time to describe the change in more detail?

Code authors are the expert on the code change

The answer is that the code author is the expert on the code. They spent a lot of time deeply engaged with this code and the problem behind it.

Independent of whether they spend two hours, two days, or two weeks, they know much more about this piece of code than the code reviewer will most likely ever learn about it during code review.

Being an expert can be a disadvantage. This disadvantage is called the expert blind spot. The expert blind spot describes the phenomenon that an expert has difficulty assessing whether something is easy or hard.

Because of this, the code author will often assume that the review of their code is easy. Three files and 50 lines changed — that’s trivial to review in the mind of the code author. Therefore, code authors often do not write code review descriptions; and if they do, they only write extremely brief ones.

Are code review descriptions unnecessary?

In a study about code reviews I led at Microsoft, we asked code authors if they think sparse code review descriptions are sufficient to understand the code. The majority of the engineers said that, indeed, there is no need for a lengthy code review description. The few words or sentences are sufficient for the code reviewer to understand the change.

Yet, when we observed and interviewed code reviewers, we saw that this was not the case. Code reviewers struggled to understand the code, and were missing a lot of context that the code author could have easily provided.

We also saw that code reviewers that were given a good code review description which included the reasons why a change was needed, were more motivated and gave better feedback than code reviewers that lacked this information.

But is it enough to link to the issue?

When I ask developers to include better code review descriptions, many argue that they did link to the issue, and that this should really be enough information for the code author to understand this change.

While it is a good practice to link to the issue or ticket behind this change, it is not enough. Issues or tickets are made for the code author. They help track the status of the work. While they also often comprise a description of the problem, this description might be outdated. In addition, they lack several important pieces of information that a code reviewer needs to understand and assess the code change. For example, a ticket or issue seldomly or never describes which alternative solutions the author has tried before.

The code review description does not have and actually should not be a copy of the issue.

Instead it should briefly summarize information from the issue relevant to the code reviewer in the code review description. The majority of the code review description should contain information specifically created to aid the reviewer in understanding the change.

So, what is this exactly, you wonder?

What should a good code review description contain?

A good code review description contains the information the code reviewer needs to understand and assess the change.

You can provide the reviewer with the following:

Explanation of the change
- the reason why this change is needed
- why you have chosen this solution approach
- which other solution approaches you considered and why you did not implement them
Information on the quality of the change
- how you tested it, including important cases you did not test
- relevant automated checks and their results
- screenshots, recordings, logs, or before-and-after measurements where useful
Guidance for the reviewer
- what should the reviewers look at
- where should they start the review
- where is the main change or risk
- whether the change needs a rollout, migration, feature flag, or rollback plan

Keep the template short enough that people complete it thoughtfully. A long checklist often becomes a box-ticking exercise. Use your continuous integration and repository rules to enforce checks that can be automated; reserve the description for context and evidence that only the author can provide.

In code review tools such as GitHub, GitLab, Azure DevOps, or Bitbucket, you can add a template that lets everyone know (code author and reviewer) what is expected from them. It’s also a great tool to make sure people remember what they should fill in and helps to overcome the expert blind spot.

Can you give me an example of a good pull request template?

Sure! For example, here is a screenshot of a minimalistic code review template from Spotify.

But you can of course include more helpful questions. I’ve created a GitHub template that comprises more template prompts, that you are free to use and tailor to your own needs.

“Pull request template”-Template ;-)

What does this PR do?

Briefly summarize what this PR changes.
Why is this change needed?
Add Screenshots/screencasts of this change (if appropriate)
Link the relevant issue, ticket, or decision.
Which alternatives or tradeoffs should reviewers know about?

How have you tested your change?

Describe the tests and other evidence you used. Note anything you did not test.

I added or updated relevant automated tests
I updated relevant documentation
I included screenshots or recordings for user-facing changes

What should the reviewer focus on?

Where should the review start?
What is the highest-risk or most complicated part?
Do you have specific questions for the reviewer?

What should the reviewer focus on?

Do you have specific questions for the reviewer?
Where is the highest risk/ most complicated change that the reviewer should focus on?
Is there a specific aspect the reviewer should focus on (e.g., correct error handling, API usage)
What is a good place to start the review (e.g., specific file/method?)
Does this need a migration, feature flag, monitoring, or rollback plan?
Are there compatibility, security, privacy, or performance implications?

You can find more inspiration for your own code review templates here: PR template from theos, Pull request template from mysql, PR template from Ionic, and one from Apache. A sweet and short pull request template from Spotify Luigi, or another short PR template from Spotify’s backstage project.

How do you add a PR template on GitHub?

In GitHub, you can add one or multiple pull request templates to your repository. Create pull_request_template.md in the repository root, docs/, or .github/. For multiple templates, add Markdown files to a PULL_REQUEST_TEMPLATE directory in one of those locations. GitHub also supports organization-wide defaults through a public .github repository. You can find a more detailed description, including screenshots on how to create a pull request template here.

How do you add a merge request template on GitLab?

On GitLab, merge request templates are Markdown (.md) files in .gitlab/merge_request_templates/ in your repository. You can select a template when opening a merge request or name one Default.md to use it by default. GitLab also supports group-level and instance-level default templates. You can read all about GitLab description templates here.

How do you add a pull request template in Azure DevOps?

Azure DevOps repositories allow you to add pull request templates to pre-populate the code review description each time a PR is opened. Azure allows to create three different templates: a default template that is used for all new pull requests, branch specific PR templates, that are used whenever the PR is opened on a specific branch, and additional that can be added in addition by the person that opened the PR. Learn more about using pull request templates in Azure DevOps here.

How do you add a pull request template in Bitbucket?

Bitbucket Cloud repository admins can configure a default description in the repository settings. Bitbucket Cloud also supports a repository-managed Markdown template at .bitbucket/pull_request_template.md; this template is branch-dependent. See the Bitbucket pull request template documentation.

Can AI write the pull request description?

AI can create a useful first draft. GitHub Copilot can generate a pull request summary, GitLab Duo can summarize code changes into a merge request description, and Bitbucket Cloud includes an AI writing assistant for pull request descriptions and comments. Availability depends on your plan and workspace settings.

These tools are best at summarizing what is visible in the diff. They may miss the reason for the change, rejected alternatives, operational risk, or tests performed outside the repository. Treat the generated text as a draft: verify every claim, remove noise, and add the context only the author knows. Never paste secrets or sensitive ticket content into an AI tool, and follow your organization’s data-handling policy.

You can also use your template as a prompt for an AI assistant:

Draft this PR description using the headings in our template. Base factual claims only on the diff and test output. Mark missing intent, tradeoffs, risks, and manual testing as questions for me instead of guessing.

This combination works well: the template defines what a reviewer needs, the AI reduces the writing effort, and the author remains accountable for accuracy.

This article showed you how you can use the code review best practice of using pull request templates to improve your code review description. If found the article helpful, please share it with your friends and colleagues.

Official source for “Use Pull Request Templates to Improve Code Review Descriptions”: https://www.awesomecodereviews.com/pull-request-template/. Last updated: July 24, 2026

Manual Stacked Pull Requests

Wed, 23 Sep 2020 13:22:11 GMT

Stacked pull requests are a powerful way to break down a large feature into smaller, meaningful subtasks. They let you keep moving forward on your work while reviewers can already start reviewing earlier parts of the change.

This workflow comes with many benefits:

shorter-lived branches
faster, more focused reviews
reviewers staying closer to the work as it evolves

In this article, I’ll show you how to set up and manage stacked PRs using only plain Git commands—no additional tools required. Because it purely uses Git, you can implement stacked-PRs with any Git-based code review tool, such as GitHub, GitLab, or Bitbucket. This will be a hands-on, technical guide.

If you’d prefer a higher-level overview of the concepts, workflows, and available tools behind stacked PRs, check out my complete developer guide to stacked PRs.

Making Large Code Changes Reviewable with Stacked Pull Requests

Code reviews are hard but worth it. However, this equation changes when the code change becomes too large. Research confirms this: the more code to review, the less effective the review.

So, we should aim to review small code changes. But how?

That’s where stacked pull requests come in. It’s a technique I also teach in my code review workshops. It allows you to break code changes into smaller and more coherent pieces that live on their own branches. In return, reviewers have an easier time understanding the code change and therefore can give better feedback in a shorter time.

So, are you ready to learn how to do it with just Git? Let’s go!

Feature Branch Workflow vs. Stacked Pull Requests

To understand the value of stacked-PRs, let’s first look at the traditional feature-branch workflow and its limitations, and then contrast it with the stacked-branch workflow.

The Traditional Feature Branch Workflow

Imagine we’re working on a new feature: “adding and deleting items from a shopping cart.”

With a feature-branch workflow, we would branch off from the main branch to implement this feature in isolation on its own dedicated branch. This means we would commit all the changes related to this feature, probably using multiple commits, on this branch. After finishing, we open one pull request, and after approval merge the feature branch back into the main branch.

This approach is common, but it has downsides for code reviews:

By the time we open a pull request, the feature branch often contains hundreds of lines of changes (several hundred lines of code is typical). Research shows this is already past the point where reviews are most effective.
The reviewer’s only option to break the review into smaller chunks is by following our commit history. But commits reflect the developer’s thought process, not necessarily coherent review units.
Commits may contain partial work, reversals, or multiple iterations of the same idea—making them harder to review meaningfully. You will find a more detailed comparison to commit-based reviews at the end.
Even if you open a WIP pull request to promote early review, the reviewer will see the code changing continually, making it hard to track progress or provide feedback.

Working with feature branches.

The Stacked Pull Request Workflow

Instead of cramming everything into a single branch and PR, stacked pull requests let us break the feature into smaller, coherent units of work.

Here’s how it works:

Each sub-task of the feature lives on its own branch.
These branches are “stacked” on top of each other, so they build in sequence.
Each branch becomes its own pull request—self-contained and reviewable.

What’s in it for reviewers?

They review coherent work items, not arbitrary commits.
They can provide feedback earlier, while the feature is still in progress.
Reviews are faster, clearer, and closer to the actual work being done.

What’s in it for the developer and the team?

You can keep working on the feature while earlier sub-tasks are already under review.
Feedback comes in earlier, so you can adapt your approach before finishing the whole feature.
Branches stay short-lived and easier to manage, reducing painful merges.
The team builds a shared understanding of the feature as it evolves, instead of waiting until the end.

In short: stacked PRs turn one overwhelming, oversized review into a series of focused, high-quality reviews—helping both the author and the team.

Note that stacked pull requests are also useful during trunk-based development. Always if we have made many changes (more than, say, 400 lines of code) and we want to ease the burden on the reviewers.

Let’s look at an example:

To split our features “adding and removing items from and to a shopping cart” into several work items, we can, for example, decide to go with an approach reflecting our system’s architecture.

Based on this decision, we start by making changes to the database layer. Then, we implement the business logic. And finally, we made the necessary changes to the UI.

Working with Stacked Pull Requests

We begin our work by creating a feature branch for the first set of changes (let’s call it fb-database, for indicating that we work on this branch on the database layer for the feature).

The git command we need for this is the git command to create a branch and check it out:

git checkout -b fb-database

As you can see from the screenshot, we are on the development branch before we create the *fb-database *branch. With this command, we now create the fb-database branch and also switch to it.

Then, we do our work and make several frequent commits until we reach a state where we think the database layer is in a good shape.

git add [somefilesthatchanged anotherfile yetanotherfile]

Now, we push create a remote branch for fb-database and push our changes to it.

git push --set-upstream origin fb-database

Then, we open a pull request just for those coherent database-changes.

Opening the first pull request for this review stack.

Tip: An even better approach is to open a “Work in progress” pull request as soon as we create the branch. This way, our colleagues can follow our progress and get already a heads-up on our work.

Opening this pull request will look exactly like we would do for any pull request. We open a pull request comparing the code of branch fb-database to the code on the development branch.

This means that reviewers see the changes that we made in comparison to what happened in the development branch. Right now, there is no difference from the example before (except that there are fewer changes that happened in this pull request).

First stacked pull request – similar to feature branch-based workflow

Creating the first stacked pull request

After we finish our first work item, we continue to work on the next work item for our feature. But instead of creating another feature branch based on the development branch, we create a branch that is based on the previous branch fb-database.

This means that all the changes we made on the branch fb-database, are already part of the code on this new feature branch, i.e. fb-businesslogic. It also means that we can continue working without being blocked, while others have the time to review our previous changes.

So, now, we are working on the changes to the business logic. And again, we open a pull request.

But now, this pull request isn’t based on the development branch. Instead, it is based on the branch fb-database.

Opening the second pull request – this one is based in fb-database

This highlights that those changes are connected, and, as a result, the reviewer sees what changed between the fb-database and the fb-businesslogic branch.

Two stacked pull requests based on two consecutive branched (fb-database and fb-businesslogic)

So, now we have implemented the UI changes. And once again, we branch off our previous feature branch (fb-businesslogic) to make those changes. We also open another pull request. Again, the PR points to the previous feature branch fb-businesslogic, instead of to the development branch.

Three stacked pull requests based on three consecutive branched (*fb-database, fb-businesslogic, fb-ui*)

Reviewing Stacked Pull Requests

So, how do we review those stacked pull requests?

The idea is that the reviewer starts with the pull request that was opened first. Then, they compare the code on the development branch with the code on the fb-database branch. These are also the first changes we made, and all other changes build upon those.

As a next step, the reviewer reviews the pull request containing the business logic. And finally, the reviewer reviews the pull request with the UI changes.

So the review direction is: fb-database -> fb-businesslogic -> fb-ui

Merging stacked Pull Requests

It’s important that reviewers do not merge code changes right after they review them. All stacked pull requests should be treated as Work In Progress pull requests until all stacked pull requests have been reviewed. This is because, we must start merging from the top, i.e., the last opened pull request. Doing otherwise will result in a state where we cannot merge our pull requests anymore.

In our example, once the reviewers reviewed all pull requests, we would merge the UI changes into the business logic changes. Then, we merge the business logic changes into the database changes. Finally, we merge the changes on the branch fb-database (which now comprises all changes) into the development branch.

So, our merge direction is: fb-ui -> fb-businesslogic -> fb- database

The merge direction of stacked pull requests follows the orange arrows.

Handling Feedback and Keeping Branches in Sync

One drawback of the stacked pull request approach is the overhead of branches that we need to keep in sync.

For example, if a reviewer comments on our pull request handling with the database changes, we would make the requested changes on branch fb-database. But this means that we have to update and sync the fb-businesslogic and the fb-ui branch.

Let’s imagine we changed the fb-database branch after receiving some feedback. Now, we have to update the fb-businesslogic branch. We have at least two options to sync our branches:

merge the two branches (resulting in 1 merge commit on branch fb-businesslogic)
rebasing the fb-businesslogic branch on the changes of branch fb-database

For both options, we first have to commit and push the changes to the fb-database branch. Then, we switch to the fb-businesslogic branch, which we want to “know” of the changes on fb-database.

git checkout fb-businesslogic

Sync using git merge:

On the fb-bussinesslogic branch, we use the merge command. Then, we push the merge commit to the remote fb-database branch so it’s visible in the pull request:

git merge fb-database 
git push

That’s it. fb-database and fb-businesslogic are in sync again. Now, we can do the same for fb-businesslogic and fb-ui. If we have merge conflicts, we have to resolve them first and then commit and push our changes.

Sync using the git rebase:

We can achieve a similar result by using the git rebase command. So, after we applied our changes to fb-database and switch to the branch fb-businesslogic, we use rebase to sync the changes.

If there is no merge conflict, we are fine. Otherwise, we have to resolve the merge conflict, and then continue the rebase using the command:

git rebase fb-database 
[git rebase --continue] #optional if you have merge conflicts
git push

Complete sync commands starting from applying changes to fb-database

Summary

We looked at a technique called stacked pull requests that can help code reviewers understand larger code changes more easily. Stackedpull requests allow you to break up large code changes and to create dependent pull requests that improve the code review process for the reviewer.

Even if the process looks tedious or scary to you, I hope you take the time to try it out on your own. Only that way you can see whether this technique makes sense for you.

Maybe you need to do it a couple of times (2-3 pull requests) before you get the hang of it. But after that, you will be used to this workflow and have integrated it into your daily routine.

Now, before I let you go, let’s compare stacked pull requests to commit-based code reviews.

Comparison to commit-based code reviews

Most tools, such as GitHub, GitLab, and Bitbucket, provide you with a list of commits that happened within a pull request.

This is handy because reviewers can click on each of the commits and see what changed just within that commit.

In theory, reviewing the code changes based on commits means that the reviewers review smaller code changes and also that they can follow the progress of the developer.

The problem of commit-based reviews

Unfortunately, most of the time commits represent the developer’s progress and aren’t meant to ease the review. This means that in some cases, the reviewer might look at changes that are undone in a subsequent commit. Also, often commits tangle together several unrelated changes.

Some commits might not even compile, or they aren’t tested. Well, from experience, I can say that many developers have a hard time committing coherent, self-contained, and working commits. Commits often just represent progress points of the developer (like breakpoints before leaving the office or going for lunch).

Still, reviewing based on commits is frequently done because when we face large pull requests, we might clutch any straw we can get.

But even if our commits represent great reviewable items, like containing all the changes we made on each individual branch, commit-based reviews still have a main drawback to the stacked pull-request approach:

Reviewers cannot approve, reject, or ask for changes on the level of individual commits. Even commenting on code changes of a singular commit is handled differently from commenting on the whole pull request. Leaving comments on a particular commit might be hard to trace for the code author and reviewer, as they do not show up in the pull request discussion.

Related work

Well, I hope I have given you a good summary of the stacked pull request approach. This should serve as another mental model and workflow to deal with code reviews within GitHub, GitLab, or Bitbucket.

Finally, I want to highlight some other blog posts that discuss the topic of stacked pull requests:
Unfortunately, the post of Grayson Koonce is not available anymore. Yet, here is a short comparison to the approach I explained: Grayson highlights a workflow in which the developer isn’t working on several branches as they do the work.

Instead, they create the stacked pull requests in retrospective by unstaging all committed changes from a single branch and using git add --patch command to divide the work.

Tip: When you have large code reviews, it can be a great practice exercise that I also sometimes use in my workshops to break up large code changes with this technique in retrospective.
Note, though, that it is an error-prone and daunting task to manually separate the changes. till, you can learn a lot about single code coherence, the single responsibility principle, and your habit of mingling and tangling unrelated changes together.

Finally, git add patch is a wonderful tool when you are dealing with relatively small and local changes that you want to separate. I use it on a regular basis. And the new git command --update-refs is also helpful to synch changes between branches.

This blog post describes this technique when working with the Phabricator code review tool.

On StackOverflow, several people discuss how to generate dependent pull requests, and there are a couple of good suggestions on how to overcome this limitation in GitHub.

Over the last few years, also tools appeared that automate or assist with the creation of dedicated review branches. One of the most sophisticated ones is Graphite. Also several open source CLI tools emerged, such as ghStack, git town, or Spr.

BTW, next to my code review workshops, I also run a newsletter providing you with awesome code review tips every other week. If that sounds interesting, get your bi-weekly dose of code review best practices below!

Official source for “Manual Stacked Pull Requests”: https://www.awesomecodereviews.com/best-practices/stacked-pull-requests/. Last updated: September 17, 2025

How to Give Respectful and Constructive Code Review Feedback

Tue, 10 Mar 2020 16:26:30 GMT

Respectful and constructive code review feedback is the basis for a fruitful and positive collaboration. In this article, you learn 10 actionable tips to get your code review feedback across in an empathic and compassionate way.

How to give respectful and compassionate code reviews

Compassion > Preciseness for code review feedback

In work environments, we focus on productivity. As engineers, we pat ourselves on the back because of our brevity and preciseness.

Still, during code reviews, this isn’t the best strategy. Taking the time to carefully phrase the code review feedback is crucial.
In my code review workshops, I often see developers who are reviewing code get into a problem-solving state of mind. In this mode, they fall back to a note-taking style of communication.

This results in code review comments such as Rename to sendMessage. or Remove this. Unnecessary.

But that’s not the right way to build relationships and collaborate with your peers during a pull request. Comments like these contribute to a harsh code review feedback culture and can lead to toxic work environments.

So, before you start a code review, make sure you take the time to carefully phrase your feedback. Recall that you aren’t giving instructions to a computer but communicating with other human beings.

Now, let’s deep dive into the 10 tips to give respectful and constructive code review comments.

1. Ask questions during code review

The best way to foster a positive code review feedback culture is to ask questions instead of demanding changes. Asking questions about the code has many advantages. It opens a dialogue and acknowledges that neither the reviewer nor the code author is always right.

Asking questions is also less confrontational. This means that the code author and the code reviewer can decide together on the right course of action. It also allows developers to discuss opinionated choices and learn from each other’s perspective.

Example: Instead of saying, “This variable should be called userId,” you can ask, “What do you think about calling this variable userId?”

Note: Rhetorical or feisty questions when commenting on pull requests, such as “Why didn’t you call the variable userId?” aren’t helpful.

You might think that asking questions is not constructive code review feedback, but in fact, it is. It helps the code author to reflect and think about your input without getting defensive.

2. Make it about the code

When you phrase the code review feedback, it is an excellent strategy to avoid addressing the code author directly. Blaming the person instead of the code leads to justification, rejections, and defensive behavior.

Example: Instead of saying "You did not close the socket connection here.", you can say "This code does not close the socket connection."

Blaming is never constructive code review feedback and won’t get you and your team far. See code reviews and coding as a team sport. Focus on facts and leave the blame game out of code reviews.

3. Clarify that it’s your perspective

While you should not blame the person writing the code, it is a good practice to use I-messages to show that the code review feedback comes from you. First and foremost, this signals that the feedback isn’t a universal statement or generalization but your observation, opinion, or perspective.

Example: Instead of saying, “This code is hard to understand,” you can say, “It’s hard for me to understand this code.”

Explicitly framing the comment as your view makes it more constructive because it distinguishes your experience from a universal claim.

For example, if you say, “Longer variable names are always better,” the code author might disagree. The statement presents an opinion as a universal truth and generalizes with the word “always.” If you say instead, “I find longer variable names easier to understand,” you turn the comment into constructive feedback. The author might still disagree, but at least they have learned something about your perspective.

It’s hard to argue against your perspective. This makes it easier for both sides to be open to looking for solutions.

4. No sarcasm when reviewing code

Research on email communication shows that people can misread sarcasm in writing and that senders tend to overestimate how clearly they convey it. Even if you believe the other person will recognize a sarcastic pull request comment, they may not interpret it as you intended. Therefore, it’s safer to leave sarcasm out of code reviews and other written feedback.

5. No condescending words

Words such as “just,” “easy,” “only,” or “obvious” can come across as belittling and condescending. It’s a good practice to remove those words from your code review feedback when they do not add meaning. Jim Fisher gives a good explanation of the problems these words can cause.

You can use Alex.js, a linter with integrations for editors and CI tools, to flag potentially condescending language such as “obviously.”

Example: Why didn't you just write the CSS in a separate file? sounds condescending and judgmental. Removing “just” improves the feedback: Why didn't you write the CSS in a separate file?

This feedback could be interpreted as sincere curiosity. But was that how you interpreted it? Or did it still sound a bit taunting?

Yeah, indeed. Many of us read this code comment as "You should have written the CSS in a separate file."

Why? In written communication, we do not have additional cues such as body language, facial expressions, or tone of voice to help us interpret a message. As a result, readers may understand a sentence differently from how the writer intended it.

6. Use emojis carefully in your code review comments

Emojis can help convey tone when written feedback lacks facial expressions and body language. However, their interpretation varies by emoji and audience, so use them only as a supporting cue—not as a substitute for clear wording.

Would you be open to moving the CSS to a separate file? 🤔

Here, the wording carries the respectful question; the emoji only supports its tone.

Still, be aware that emojis do not make up for harsh or toxic code review feedback.

7. Explain your reasons for the requested PR change

If you suggest a code change, then you should also explain the reasons why you suggest this change. This is unnecessary if you are 100% sure that the code author is aware of the reasons. Still, most of the time, adding a brief explanation to your pull request comment is better than assuming the code author knows your reasons. This differentiates plain criticism from constructive code review feedback.

Example: Instead of only saying, “This code does not close the socket connection,” explain the consequence: “Leaving the socket open can leak system resources and keep the connection open longer than intended.”

8. Give guidance during code reviews

The code reviewer does not need to take over the code author’s job. Still, it is good practice not only to critique an aspect of the code but also to guide the code author toward an improvement.

Sometimes this can be a quick note about a method or API that can be used. For example, in our socket comment, you could add: “Please use the close() method to close the connection.”

Often, code authors need guidance when the feedback is less clear. For example, recall the example where we told the code author that we did not understand the code. Here, it’s crucial that we add some guidance on what the code author can improve to make the code review feedback constructive.

This means adding guidance to “It’s hard for me to understand this code,” such as “I think more expressive variable names would help me understand it.”

Similarly, code authors need guidance when reviewers critique architectural or design changes. For example, saying “This code should be more performant” isn’t constructive. As a code reviewer, you do not need to come up with a complete solution, but your feedback should briefly lay out your improvement strategy. Again, this differentiates unconstructive from constructive code review feedback.

9. Add value for the code author

Whenever you give code review feedback, it is important to be aware of the context. This will affect how much explanation or guidance you need to provide, and can also affect the tone.

To understand how you can add the most value for the code author, consider whom you are giving feedback to. Is this a colleague you know well, a new hire, or someone from another team? How much guidance and explanation do they need for this code change?

Also, think outside the box. For example, instead of marking every spelling mistake, you could point the code author to a spell-checker plugin or offer to help them install it in their IDE. That way, you can focus on giving respectful and constructive code review feedback instead of performing tasks that tools can do better, faster, and automatically.

10. Assume miscommunication over malice

Finally, always assume miscommunication over malice during code reviews.

As we already discussed, in written communication, the receiver of the message must interpret the message with no natural clues, such as body language, facial expression or tone. Several studies show that this can easily go wrong. Misinterpretations happen frequently and are, in addition, hard to detect on the sender’s side. The best way to limit misunderstandings is to err on the side of caution.

But whenever code review feedback feels harsh, or you feel attacked or belittled during a pull request, it is good to take a step back. Give yourself time to calm down before responding. Then remember that, most of the time, people have good intentions. With that mindset, you can address the feedback and help your peers convey their message more compassionately.

What’s next? Read about code review challenges that slow teams down, the fundamentals of effective code reviews, and proven code review best practices.

Finally, join my Awesome Code Reviews newsletter for research-based insights and practical guidance on code reviews and software engineering. If you want to follow my upcoming Code Review Book, you can also join the early-reader group.

Official source for “How to Give Respectful and Constructive Code Review Feedback”: https://www.michaelagreiler.com/respectful-constructive-code-review-feedback/. Last updated: July 24, 2026

Code Reviews at Google

Mon, 29 Jul 2019 08:59:30 GMT

Code reviews at Google play an important role as an engineering practice and have been adopted already in the early days of Google. Still today, they are used to keep the code base clean and consistent, and to ensure no arbitrary code is committed. Even though the code review process looks similar to code reviews at Microsoft, there are some Google specifics that allow for a particular lightweight code review process.

So let me show you what code reviews at Google look like and what sets them apart from code reviews at Microsoft. In particular, I’ll show you what allows the 25,000 engineers at Google to review their code much faster than at other companies of this size. So, let’s get started.

Code Review Study at Google

Caitlin Sadowski, a researcher at Google, and others have performed a study to understand Google’s internal code review processes. This study is similar to the code review study at Microsoft, which makes it interesting to compare the code review processes at the two companies.

A typical code review process at Google

A typical code review at Google looks very much like a typical code review at Microsoft. Let’s look at an example, by imagining a Googler’s code review process. Let’s call him Mark.

Preparing code for review

It all starts after Mark has made some changes to the code and wants those code changes to be merged with the shared codebase. At Google, code reviews are, similar to Microsoft, done with the help of a tool. So before Mark sends his code changes out for review, he uses the tool to look through the code one last time.

Critique, Google’s internal code review tool, offers some diffing capabilities that make it easy for Mark to spot errors and see what has changed in this new version of the code.

Before sending the code out for review Mark needs to perform another step. Running the code through a static analysis tool. So, Mark runs, for example, Tricorder, a tool widely used at Google, and reviews the results of the static analysis tool. When he is happy with his changes, he sends the changes to at least one code reviewer.

Reviewers give feedback

The code reviewer carefully looks through the code and leaves comments if she sees a problem or needs some clarification. Mark then addresses each comment either by changing the code or replying to the comment. If Mark made some changes to the code under review, he uploads the new version for reviewers to check again. If a reviewer is satisfied, she can approve the change by marking it as “LGTM” (looks good to me). To be able to commit the code to the shared codebase, at least one reviewer must approve the code.

Looking at this code review lifecycle from a distance it looks like a carbon copy of a code review at Microsoft. But, there are profound differences that I’ll show you now.

Company-wide policies for Approval

First of all, Google requires each code change to be reviewed. No exceptions. Period.

At Microsoft, on the other hand, code reviews, including how and what needs to be reviewed are at the discretion of the divisions or teams. Some teams skip, for example, code reviews for small and trivial changes. In general, there aren’t any company-wide policies around code reviews. Teams and divisions decide on how many code reviewers are needed, and how code reviews are linked with testing and static analysis activities and more.

At Google, each code change is reviewed. Period. Click to tweet

Code reviews at Google address ownership and readability

Also contrary to Microsoft, Google has some company-wide requirements that must be fulfilled by the code reviewers in order to be able to approve the code change. One has to do with Google’s strong code ownership. Each directory of the codebase is explicitly owned by a set of people. To be able to get the code change approved, at least one reviewer must be an owner of the code under review. That person acts as a gatekeeper. Only if this person gives his or her okay, code can be checked in.

Another strict requirement is that at least one person on the review must be trained in code “readability”. What this means is that this person must have obtained a readability certification. This certification shows they’ve demonstrated they know how readable and maintainable code looks.
The readability certification must be obtained per language. Having such criteria is a great practice to ensure consistency in style and design.

To get decision power, reviewers at Google must obtain a readability certificate that shows they understand what readable code looks like. Click to Tweet.

Requirements for reviewers aren’t focused on seniority or status

So, while many other companies, including several divisions at Microsoft, rather look at the seniority of the reviewer, the area of expertise or the hierarchy to grant decision power, Google looks at ownership and readability certification.

This addresses some common code review pitfalls. Requiring senior developers to approve code can easily lead to work overload and in turn, create bottlenecks.

On the other hand, it is also important that enough people have such a readability certificate. Otherwise, it also creates bottlenecks for reviews. And we all know, waiting on code review feedback is one of the main pitfalls during code reviews. But while it takes quite some effort to obtain readability certification, it is easier than changing hierarchy or seniority.

How to get a readability certification

To demonstrate their ability to review code for readability, developers at Google go through a “review of their code review practices”. Therefore, the developer submits code changes to a team of readability experts. Those will inspect the code. But this inspection is not like a normal code review. No, readability experts look at the code with much more scrutiny. The purpose of such reviews is to point out every little mistake and every potential for improvement, especially in terms of coding conventions and coding style. Also, nitpicking issues such as indentation or extra spaces are part of this learning process. For the interested, you can find Google style guides for various languages here.

Once the experts are convinced that the developer learned and is able to apply Google’s coding style and conventions, they issue the readability certification.

What it takes to get code approved

So to recap, to get your code approved at Google, you need at least one person on the code review that has ownership over the code and the right readability certification for the used language. If those two criteria are met, you are good to go.

No rule without exceptions. Also at Google teams exist where more than one developer must approve or where different criteria for reviewers are enforced. But, the general rule is one developer’s approval is enough.

Code reviews at Google are light-weight and fast

Google explicitly wants its code review practices to be lightweight and fast. And even though Google enforces the ownership and readability criteria for approval, the code review process is – with 4 hours on average – really fast. Small changes are reviewed within 1 hour, and larger ones within 5 hours. Other companies report average turnaround times of over 15 hours.

At Google, code review are on average completed within 4 hours. Click to Tweet.

So, how does Google do code reviews so fast?

Well, looking at the data reported, we can see that there are two important factors: the number of review participants and change size.

Requiring only one reviewer speeds up code review times

One of the most interesting findings from the study is that more than 75% of the code reviews have just one reviewer. That’s unusual. Especially because studies have shown that two reviewers tend to give more valuable feedback.

Requiring only one reviewer seems like a conscious decision at Goggle and trades review rigor for speed. Only that way, Google can realize fast turn-around times. Skipping the need to wait for another person reduces a lot of complexity. But it hurts review rigor, as also the study mentions. How much this costs in terms of quality is unknown. Still, Google seems to have great outcomes with this set-up.

Small change sizes are essential for fast and high-quality code reviews

Another crucial insight from this study is the size of the change. Can you imagine, 90% of the code reviews have fewer than 10 files changed? That’s truly impressive and also explains why code reviews at Google are lightning-fast. Most of the changes also have only around 24 lines of code changed. That’s a much smaller change size than reported by studies of other companies, including Microsoft.

Reviewing small, coherent changes is a proven code review best practice. First, it increases the review speed. But, as we have seen in our study on valuable code review feedback, it also improves the value of the code review feedback. The usefulness of the code review feedback decreases as the size of the code reviews increase. Googlers know that and submit frequently and small code changes. How smart!

Code Reviews at Google are fast for two main reasons. First, 90% of code reviews at Google comprise less than 10 files. Second, 75% of the reviews have only one reviewer Click to Tweet.

Are code reviews worth the effort?

While analyzing code review practices and tools at Microsoft, I often thought about what it actually means to provide value during code reviews. When are code reviews worth the time a team spends on them?

To answer that question, I turned to the developers and ask them why they are doing code reviews and when they get value out of them.

Well, turns out code reviews must lead to changes to provide value. Even though it is okay if some code reviews don’t lead to any changes, it is important that a majority of them actually have an impact on the code. Otherwise, we could just skip them, right?

Code reviews must lead to change to unfold their true value. Click to Tweet.

So, coming back to the Google study, I found it interesting that the researchers also had the premise that if there is no action taken, the code review could have been skipped. The good news is 80% of the code reviews at Google do require the developer to take action. This clearly shows that code reviews have an active impact on the codebase. But what about the 20%? Is that time wasted?

Well, things are not that simple. Fortunately, code reviews provide a broad set of benefits.

Motivations and benefits for code reviews at Google

Even though code reviews are often associated with finding bugs, several studies on code reviews show that the benefits and motivations for doing code reviews go far beyond that. Also, Googlers are aware that the benefits of code reviews are manifold, especially if code review best practices are followed. The original vision of the employee that introduced code reviews at Google was to force developers to write code that other developers understand.

In the study, Googlers report the following motivations for code reviews:

Education (mentoring, learning for developers, knowledge dissemination)
Maintaining norms (such as having adequate tests, consistent style and design)
Gatekeeping (ensuring security, and having an additional safety net so that a single developer can not commit arbitrary code) and
Accident prevention (this includes making sure bugs and defects are prevented as good as possible, and that the source code is of high quality).
Tracing and tracking decisions (understanding the evolution of the code and why and how changes have happened)

Reasons for code reviews at Google

Another interesting finding from the code review study at Google was that the motivations and expectations for doing code reviews depend on the person’s role and responsibilities. A manager, for example, is more interested in the benefit of creating a coherent coding style at the codebase than a single developer. On the other hand, developers are more concerned with finding defects or bugs.

The reasons for code reviews reported by Googlers are aligned with the reasons reported by Microsoft engineers, except that Microsofties do not describe code reviews as a way of “gatekeeping”. Security checks, for example, aren’t part of the normal code review process at Microsoft.

Google’s code review tooling

At Google, code reviews are done with the help of tooling. Two main code review systems are predominant at Google. For open-source code and code shared with collaborators outside, like Go, Chromium, Android Googlers use the Gerrit code review tool. Gerrit is an open-source code review tool that integrates with Git.

For the internal code, on the other hand, Googlers use an internal code review tool called Critique. Critique is a rewrite of Mondrian. There aren’t any detailed description of the functionality of Critique, but Googlers seem to be pretty happy with the workflow and functionality.

A lot of code reviews at Microsoft are also performed via tooling. But at Microsoft, other forms of code reviews, such as over the shoulder reviews, have their fair and justified warrant. Sometimes, nothing can beat a face-to-face conversation.

Google’s uniformed process is optimized for speed

To sum it up, Google has clear guidelines on what it takes to get a code review approved. What stands between you and the commit to the shared codebase is a review approval from at least one person with code ownership and readability certification. That most reviews only have one reviewer takes also a lot of complexity out of the code review process. Company-wide code styles, make it crystal clear how readable code must look like. This combined with the small code change sizes allows Googlers to expect code review feedback in 1-5 hours.

Similar to Microsofties, Googlers are very satisfied with the code review process and find it a valuable engineering practices.

If you and your team want to boost your code review practices, book a code review workshop with me. I have already worked with many product teams around the world.

Credit where credit is due

This blog post is based on the wonderful study of code reviews at Google done by Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko from Google and Alberto Bacchelli from the University of Zurich. I also want to thank Robert Göritzer and Leif Singer for taking the time to read my drafts and to provide feedback.

Official source for “Code Reviews at Google”: https://www.michaelagreiler.com/code-reviews-at-google/. Last updated: January 17, 2023

Code Review Best Practices

Mon, 29 Jul 2019 08:59:30 GMT

To learn more about code review best practices read the following articles:

Official source for “Code Review Best Practices”: https://www.awesomecodereviews.com/best-practices/. Last updated: January 22, 2022

Code Review Fundamentals

Mon, 29 Jul 2019 08:59:30 GMT

If you want to learn the fundamentals of code reviews, have a look at the following articles:

Official source for “Code Review Fundamentals”: https://www.awesomecodereviews.com/fundamentals/. Last updated: June 10, 2025

Code Reviews at Microsoft

Wed, 27 Mar 2019 08:00:57 GMT

How does Microsoft do code reviews? Have you ever wondered how one of the largest software companies worldwide ensures high-quality code through code reviewing?

So did I. That’s why together with my colleagues, we investigated how code reviews are done at Microsoft. Is it a common practice? Are developers required to do code reviews? And which tools do they use?

Let’s find out in this post, which is part of a larger blog post series about code reviews showing you code review best practices, code review challenges, how code reviews work at Google, and much more.

To begin with, let me give you some key information about Microsoft. Microsoft has around 140.000 employees. Approximately 44% of them, which means over 60,000 employees, are engineers. Several products such as Office, Visual Studio or Windows are developed by thousands of engineers that work on the same codebase simultaneously.

I say all this to give you some context and perspective on what it means to coordinate and manage the software development process. As you can imagine, it is a non-trivial task to ensure code developed by different sub-teams actually works perfectly together. And code reviews play a big role at Microsoft to allow smooth collaboration at such a large scale.

Code reviews at Microsoft are an integral part of the development process

One of the important facts when it comes to code reviews at Microsoft is that it is a highly adopted engineering practice. Thousands of engineers perceive it as a great best practice. And most high-performing teams spend a lot of time doing code reviews.

At Microsoft, code reviewing is a highly adopted engineering practice and perceived as a great best practice. Click to Tweet.

Investigating code reviews at Microsoft

Because code reviews play such an important role in the Microsoft development process, it was an ideal target for us to dig deeper and understand the benefits and drawbacks of this practice. In a large-scale study on code reviews at Microsoft, we interviewed, observed and surveyed more than 900 developers about their code review practices.

We aimed to understand how exactly code reviews are done at Microsoft. We wanted to know, which code review pitfalls developers face while doing code reviews, and which code review best practices they develop to overcome those challenges.

What can you learn from code review practices at Microsoft?

Most of the lessons learned are as valuable to smaller teams and organizations as they are for large teams and large organizations. In case your team does not do code reviews yet, I distilled our findings in a way that shows you the benefits of the practice. I also explain what the code review life cycle looks like so you can incorporate that practice into your development process.

If your team already does code reviews, you can compare your practice with the code review practice at Microsoft. Does your code review lifecycle look different? In the next posts, you learn from code review pitfalls and the code review best practices. With this information, you can set out to see if your team already implements all the best practices I present and overcome challenges. But, let’s get started:

How often do Microsoft engineers perform code reviews?

In this study, 36% of the developers said they perform code reviews multiple times a day. Another 39% of the developers said they do code reviews at least once per day. 12% do code reviews multiple times a week, and only 13% said they did not do a code review in the past week.

How often do Microsoft developers review code?

This means that developers at Microsoft spend a significant amount of their time on code reviews. So it is important to make sure that this time is spent worthwhile. But, which benefits does code reviewing provide?

Developers at Microsoft spend a significant amount of their time on code reviews. Click to Tweet.

Which benefits does code reviewing provide?

The most important reasons developers mentioned as benefits of code reviews are to improve the code quality and to find defects in the code. Another important benefit of code reviews is knowledge transfer.

Knowledge transfer means that team members that review each other’s code, become familiar with a larger part of the code base. But, it also means that code review best practices are developed within the team. Another advantage is that new team members and junior developers can learn and improve their coding skills while reviewing or getting feedback.

If developers discuss alternative solutions during code reviews, it not only improves the code base but has also a learning effect for all involved. Learning, mentoring and self-improvement are therefore all reasons code reviewing is perceived as such a beneficial practice at Microsoft.

Benefits of code reviews

Developers do code reviews to improve the code, to find defects, but mostly to increase the knowledge transfer amongst team members and for the learning effects. Click to Tweet.

But how does a developer typically do code reviews?

Code reviews can be performed in many ways. Sometimes, it is as informal as one developer walking over to another developer’s desk to look at some code together. Other times, teams review code together in groups. But the most likely scenario you will encounter for code reviews at Microsoft is that code reviews are done with the help of tools.

Code reviews at Microsoft are most often done via an internal tool

There is a wide variety of code review tools available, and at Microsoft, teams are free to choose their tooling. In 2016, 89% of the developers indicate to use the CodeFlow code review tool. I will explain more about this code review tool at Microsoft later. Since then, and with the rise of Git, the tooling landscape has changed. I’ll add updated numbers as soon as they become available. But, let us consider a typical review situation:

Let’ imagine a developer at Microsoft, and let us call her Rose. Rose just finished a part of a feature and now wants feedback from her peers.

How does Rose start a code review at Microsoft?

Well, as said, Rose is ready to get some feedback. Therefore she first prepares the code for review. This step includes that she opens the code review tool, that allows her to preview the code change. The code review tool performs some diffing tasks that help Rose to see exactly which changes she has done.

After carefully reviewing those changes, she prepares a small note that tells the reviewers what she did and why she did that. This note helps the reviewers to understand the purpose of the code change and its motivation. Now the code is ready to be sent to the reviewers.

How does Rose select the right code reviewers?

Many experienced developers know who should be on the code review. Nevertheless, for people new to the team, or for new areas of work the selection can be a bit more tricky. If Rose does not know who she should add, she would either look at the team policies or ask her colleagues. She can also use a recommendation feature of the code review tool that helps select reviewers based on experience and knowledge of the code base.

Who are appropriate reviewers?

Rose selects reviewers that she thinks can contribute their knowledge to this piece of code. The reviewers are often other developers, but can also include other stakeholders, such as dev-ops engineers, UI experts, or also managers. Some reviewers are selected for their expertise, others are selected in order to stay informed about a coming change.

Rose requests feedback from her peers

Once everybody is selected, Rose sends out the code review (by pressing the send button 😄). The code review tool sends notifications automatically to inform everybody that a code review has been created. Notifications are sent to all reviewers. But, often additional parties, such as managers or product managers of other teams are also added to the notification list and are automatically informed for each review. Those notifications allow them to stay in the loop. They are not required to perform the review.

Receiving feedback is an iterative process

Once Rose’s colleagues have time, they will look at the code review. Each reviewer can annotate the code and add comments. Once finished commenting, the reviewer sends the annotated code back to Rose. Rose can now work on the comments and prepare a new improved version of the code.

Reviewers normally look for things like: does the code look bug-free? Is there an architectural problem? Are there minor issues such as missing comments, or spelling mistakes? Not all comments are equally valuable. But, there are several best practices to boost the value of code review comments.

Rose prepares a new improved version of the code

Rose works on the feedback by fixing and addressing the suggestions. If Rose sees that there are some misconceptions or other contentious issues, she might walk over to a colleague to discuss this in person. That’s sometimes easier and more personal than through the tooling.

Anyway, once she finished working on all the feedback, she sends a new version of the code to the reviewers. That new improved version is called a revision.

If needed, she will receive further feedback. Whether or not this cycle continues for a few times depends on the type of change and its quality. For simple and small code changes, often only one code review revision is needed. For other more complex changes or changes in the problematic code, several iterations might be necessary.

It is totally normal, and partly desirable that this code review feedback cycle sparks some discussions between the author and the code reviewers.

All reviewers approve and Rose checks-in the code

After this review cycle, reviewers mark the code as okay, and Rose can finally check-in the code into the common code base.

Some teams have policies, that allow the developer to check-in the code before an actual review is completed. This is normally restricted to small and trivial changes, in order to allow asynchronous reviews and to speed up development.

All steps I describe are part of a typical code review life cycle at Microsoft and are performed by all teams. Depending on the team’s policies, teams are more strict or rigorous for each of the steps.

Not all teams are the same

As you can imagine, not all 60,000 engineers, and not all of the thousands of teams do the same. Some teams at Microsoft have additional steps or tools they require during the code review life cycle. I want to give you a short overview of some additional steps that teams add to the code review process.

Code reviews including test results

What you do not want is to waste time by reviewing “automatically detectable” buggy code. I mean, if you could run automated tests and realize that the code does not work as expected, then, that’s what you should do: Run the tests before the review.

That’s why some teams require test results to be submitted with each code review. This way nobody can forget about running the tests. And it assures that the tests have actually run and passed for the given code change.

Other teams went even a step further and configured the code review tool in such a way that for each code review a developer submits, a build is triggered. That build contains that exact change, and also starts a series of automated tests. The results of this build and these tests are attached to the code review. Configuring it this way ensures that the code changes have been tested with the latest code changes from the common code base.

Code reviews including user interface

If changes affect the user interface, it is also a smart idea to require the developer to submit a screenshot. That way the code reviewer can see the effects of the code change without running the code. Second, the code reviewer can spot discrepancies when running the code on her machine.

Code reviews including static analysis

Static analysis tools are only as good as their configuration, but, in terms of styling issues, they can save a lot of time for code reviewers. Some teams at Microsoft use automated static and dynamic analysis tools as dedicated bot-reviewers. Those bots comment on code styling and other static issues. Thus, freeing up time for human code reviewers to perform more interesting tasks.

Microsoft’s code review tool

For many years, one of the de facto standards for code review at Microsoft was an internal tool called CodeFlow. This is a sophisticated code review tool that supports developers and guides them through all steps of a code review. CodeFlow helps during the preparation of the code, automatically notifies reviewers, and has a rich commenting and discussion functionality.CodeFlow is a UI-heavy tooling, much like Word or PowerPoint, as you can see in the screenshot below.

CodeFlow’s interface explained

You can skip this if you want, but for all interested, I am walking you through the interface of CodeFlow. Looking at the screenshot, on the left (A) you see all affected documents.

Also on the left, you see (B) the list of reviewers assigned to the review as well as their status (e.g., signed-off or pending). The active document is shown in the editor (C). At the bottom, you see (D) a list of comments for all documents.

On the other hand, in the active document (F) is one single comment. This comment is connected to the concrete part of the code (i.e., one word in a line). Finally, at the top, you see the overall status of the code review. In this case, completed. The numbers before signal the different revisions. In this review, there have been five revisions.

Commenting functionality

One of the nicest features of CodeFlow is its commenting functionality.

A code reviewer can select very precisely the parts of the code she wants to comment on. For example, a reviewer can even highlight just one or two characters in a line, instead of highlighting a whole row. Then, the reviewer can attach a comment to that selection.

The code author or other reviewers are notified of this comment and can start a conversation in the form of a thread around this comment.

Discussion functionality

This commenting functionality feels like commenting on social media platforms, such as Twitter or Facebook. Therefore, the commenting experience in CodeFlow feels very natural and allows for rich conversations and discussions. Another nice perk is the possibility to assign a status to each of these comment threads. The status can, for example, be “won’t fix”, “resolved” or “open”.

Comparison between code review revisions

A helpful feature is the possibility to select two different revisions of the code review and compare the differences between that. This means that you can see exactly which changes the code review author has performed between one code review revision and another one. That’s super handy to track the progress of the review.

Code review analytics tool

Developers spend a substantial amount of their time performing code reviews at Microsoft. To ensure this time is well spent, Microsoft has its own code review analytics platform.

This platform stores all code review data starting from the code under review, the developers involved in code reviews, to all comments of the developers. Even the code changes for each of the revisions can be traced back.

This code review data is the base for several empirical studies on code reviews at Microsoft. It is also used by many product teams for tracking their productivity and to understand their own code review practices. Also, many of the insights I share in this blog post series about code reviews at Microsoft stem from studies and analyses that involved this code review data.

The future of code review at Microsoft

With Micorosft’s engagement and acquisition of GitHub change was inevitable. The change is visible by the vast adoption of Git as a source control tooling within Microsoft for example. But, this also means that at Microsoft code reviewing in the form of pull requests is on the rise.

I’ll definitely plan to address code reviewing using pull requests at a later time.

Want more on Code Reviews?

Check out my code review workshops! Yes, through remote and onsite workshops, I help teams all around the world to make code reviews their superpower. ♥️

Also, have a look at my other articles about proven code review best practices, learn about which code review pitfalls you should avoid, and also how to boost your code review value with great feedback.

Credit where credit is due:

I would like to mention my wonderful colleagues at Microsoft and the University of Victoria that have been part of this study: Chris Bird, Jacek Czerwonka and Laura Macleod and Margaret-Anne Storey. I loved working with you on this ♥

To stay in the loop and never miss a blog post, sign-up to my email list. Also, let’s connect on Twitter. I prepared an exclusive Code Review e-Book for my e-mail subscribers to help you remember the code review best practices. I also added other great insights and summaries about code reviews. Get the 20-page insights to code reviews now. Not a subscriber yet? Just sign-up.

Official source for “Code Reviews at Microsoft”: https://www.michaelagreiler.com/code-reviews-at-microsoft-how-to-code-review-at-a-large-software-company/. Last updated: January 17, 2023

The Ultimate Code Review Blog Post Series

Sun, 17 Mar 2019 13:40:13 GMT

In this code review blog post series, I share my experiences and lessons learned about code reviewing. Primarily, I show you code reviewing best practices to boost your code quality. But, you also learn which pitfalls to avoid while performing code reviewing.

The foundation of those code review blog posts is my experience analyzing and improving code review practices and tooling at Microsoft. I worked with hundreds of engineers and analysed thousands of code reviews. You can see this code review blog post series as an intense crash course to learn about code reviewing best practices.

Get Dr. Greiler's exclusive Code Review e-Book describing all code review best practices at Microsoft and Google. It also had more great insights and a complete code review checklist. Get the 20-page insights to code reviews now. Not a subscriber yet? Just sign-up below.

What is Code review?

Code reviewing is a widely adopted and adapted engineering practice. Its main aim is to improve software quality. In addition, sharing knowledge among team members is another important benefit of code reviewing.

Even though code reviewing provides several other benefits, you have to be aware to follow best practices. Otherwise, you might tap into several pitfalls.

Microsoft’s code review process

I have been working at Microsoft as a software engineer and researcher for several years. My main focus was to analyze and improve engineering practices and tools. One of the key areas I focused on was code reviewing.

In this blog series, I am going to share the key insights and lessons learned about code reviewing at Microsoft. All of them are backed by research and are grounded in actual experiences and knowledge from high performing engineering teams. At Microsoft, I performed several large-scale studies involving thousands of engineers and millions of code review comments. The lessons learned presented in this code review blog post series are derived from those empirical studies.

The series consists of 9 blog posts. You can read each one of them separately. Still, you might get the best out of it reading it consecutively.

Code Reviews at Microsoft
In this post, I explain how a common review process looks like at Microsoft, and which code review tool is mostly used at Microsoft.
Code review pitfalls: learn which problems slow your team down In this post, I deep dive into the main code review pitfalls teams face when practicing code reviews.
Proven Code Review Best Practices
Learn which code review best practices make your team productive and boost code review feedback value.
How to give great feedback
The benefits of code reviews rise and fall with the quality and value of the feedback. In this post, I show you proven ways to boost your code review feedback.
Code Reviews at Google Code reviews at Google are lightweight and fast. Code reviews are completed in under 5 hours. That’s much faster than most other large software companies. In this post, I show you why.
Code Review Checklist
If you want to boost your productivity and your rigor at the same time, a code review checklist is what you are after. This one is also downloadable.
Don’t criticize my code
Even the most useful, well-intended and well-written feedback can sting. This post discusses why that is and what you can do about it.
Don’t teach during Code Reviews
In this post, I’ll show you a common pitfall you should avoid when you set out to teach during code reviews.
Organizational Trade-offs to consider during Code Review Process Design
Even if you are aware of all the best practices, there are several trade-offs you have to keep in mind. For example, do you favor review speed or review rigor? In this article, I dive into this topic.
Wrap-up post

Official source for “The Ultimate Code Review Blog Post Series”: https://www.michaelagreiler.com/code-review-blog-post-series/. Last updated: March 17, 2019