A code review checklist for .NET pull requests should start by checking correctness, test coverage and clarity, and only then move on to detailed questions of design and operations. For teams using Azure DevOps, it is most effective when combined with build validation, clear review rules and small changes.
A pull request is the formal proposal for a change before it is merged. In Azure Repos, this process can be reinforced through branch policies, for example with a minimum number of reviewers, comment resolution and the requirement for linked work items; according to Microsoft Learn on the pages “Branch policies overview” and “Branch policies”, accessed on 01/11/2026, these policies are disabled by default.
In day-to-day work, a checklist is effective when it stays concise and is tied directly to the review process:
- a small number of fixed checkpoints,
- automatic rules for repeatable checks,
- manageable changes rather than oversized pull requests.
That last point in particular often determines whether a review is thorough or merely superficial. For that reason, it helps to set a clear team rule for how large a pull request may be.
Correctness and tests
Start with the core question: does the pull request fulfil the linked work item from both a business and technical perspective, without bringing in unnecessary additional changes? The more clearly this question can be answered, the more reliable the review will be.
Check whether the goal and scope of the change are clearly described in the pull request and whether the link to the work item remains visible. In Azure Repos, the “Check for linked work items” policy can make this connection mandatory; Microsoft lists it in “Branch policies overview” as a branch policy, accessed on 01/11/2026. If your team often opens changes for discussion first, it may also help to look at drafts in the review process.
In the actual code review, it is not enough to read only the obvious main path. Also check:
- edge cases and empty inputs,
- error paths and exceptions,
- return values and side effects,
- changes that affect more than the requirement calls for.
In .NET code, new or changed logic should be covered by suitable tests. Test names should describe the expected behaviour, not just technical details of the current implementation. Also consider how meaningful the tests are: do they cover the relevant behaviour, or do they merely confirm the existing implementation? For bug fixes, it is especially useful if a test reproduces the original defect or now clearly records the intended behaviour.
Finally, check whether the build and tests run in Azure Pipelines as build validation on the pull request. Microsoft lists “Build validation” in “Branch policies overview” as a branch policy that is disabled by default, accessed on 01/11/2026. Size matters here as well: if a pull request becomes too large, it becomes harder to review properly and comments are more likely to stay at surface level.
Design and naming
Check whether the change fits into the existing structure rather than introducing a new one on the side. A pull request becomes harder to review if it mixes a business change, restructuring and new technical patterns all at once.
It also helps to take a brief look at the boundaries of responsibility: a class should have a recognisable purpose. Orchestration, business rules, data access and infrastructure code should not be bundled into the same method or type without good reason.
For refactorings in particular, check whether behaviour and structure remain separate. If the two are mixed together, it becomes unclear what comments and approvals actually refer to.
The same applies to naming: names should convey intent and match the system’s business vocabulary. This applies not only to public types and methods, but also to local variables, DTOs and test cases. A DTO is a simple data carrier used to exchange values between parts of a system.
A few questions are often enough:
- Is the name understandable from a business point of view?
- Does it introduce a new concept even though one already exists?
- Does a comment explain real context, or just bad code?
If you want to integrate reviews more deeply into your process technically, depending on your team it may help to use control via the REST API or events via Service Hooks.
Security and secrets
First check whether the change opens up any new trust boundaries. This concerns not only classic secrets, but also any point where data reaches other processes, services or protocols. A trust boundary is the transition between areas with different access or protection requirements.
Pay particular attention to these points in the pull request:
- new environment variables, app settings or service connections,
- additional permissions for managed identities, service principals or users,
- changes to pipeline definitions, templates and deployment steps,
- new export paths for logs, events, artefacts or diagnostic output,
- sample and test data containing personal data or real internal identifiers.
It is also helpful to ask whether the change preserves the principle of least privilege. If a service account is granted broader permissions, the pull request should clearly explain why this is necessary and how access remains limited.
For Azure Repos, Microsoft names two sensible guardrails for sensitive areas in “Securely use repositories and pull requests” (accessed on 01/11/2026): automatically included reviewers for sensitive paths and very limited permissions for “Bypass policies when completing pull requests” and “Bypass policies when pushing”.
As soon as review features or agents process code, pull request content or metadata, the data path also needs to be part of the review. For data protection, DORA, NIS2 and co-determination, you should clarify the legal position with a lawyer and your data protection officer as appropriate. For the current status of planned data paths, identities and guardrails, the security and data page is helpful.
Performance and logging
During the review, look at the runtime profile of the change, not just whether it behaves correctly. Particularly critical are new loops over large volumes of data, repeated materialisation of queries, unnecessary serialisation and additional network calls in paths that are already heavily used.
In .NET, it is worth taking a careful look at asynchronous code. What matters less is whether async appears everywhere, and more whether I/O remains cleanly separated from CPU work, tasks are passed through correctly and there are no blocking calls in request or job paths. A hot path is a code path that is executed particularly often and is therefore important for load and latency.
For logging, the principle is: little, but useful.
Check in particular:
- whether log entries contain the necessary business and technical context in the event of errors,
- whether log levels match the event,
- whether correlation remains visible across request, job or message boundaries,
- whether personal data, secrets or internal identifiers are not being logged unnecessarily.
If operational behaviour changes, it should also be visible how you will later recognise success and problems. This includes, for example, suitable metrics, health signals and clearly named error paths. Even for additional automated checks in the pull request, the limit still matters: context on load, diagnostics and operational consequences must be assessed by the team itself.
What tools should check instead of people
Automate only what can be assessed reliably using fixed rules. In the review process, this mainly means results with clear inputs or outputs: successful or failed, present or not present, fulfilled or violated.
Typical examples are:
- compilation and test execution,
- formatting and analyser rules,
- the requirement for linked work items,
- comment resolution before completion,
- build validation and status checks.
Status checks are feedback from other systems directly on the pull request. They are suitable where a result is available in machine-readable form but does not make sense to model as a reviewer vote.
For review rules, it is worth looking at the finer details. In Azure Repos, you can require not only a minimum number of reviewers, but also specify whether an approval of the latest iteration is required after new pushes. This prevents an earlier approval from silently being counted for later code as well.
For AI-supported checks, this boundary is even more important. According to Microsoft Learn on the pages “Copilot code reviews” and “Review pull requests”, accessed on 01/11/2026, the feature in Azure Repos leaves a Comment review. It therefore does not replace a required approval and does not block a merge. Because preview features have no SLA and may change, teams should treat such checks as an additional signal, not as a core review rule.
If you want to sharpen your boundary between automated and manual review, a simple question helps: does this point require judgement, or only a rule?
Common questions you may ask yourself
How can I tell whether a checklist still works in everyday team practice?
It works if it can be applied quickly before the first comment and does not need to be explained during the review. A simple test is this: if two reviewers use the list on the same pull request, do they focus on similar points without lengthy interpretation?
Other signs are warnings:
- points are hardly ever mentioned,
- the same question appears twice in different wording,
- the list mixes mandatory points, guidance and exceptional cases.
If that happens, cutting items is usually more helpful than expanding the list.
Which Azure Repos rules make sense first for important branches?
For central branches, you should start with the rules that make the process clear. In “Securely use repositories and pull requests”, accessed on 01/11/2026, Microsoft names at least two reviewers, linked work items, comment resolution, build validation and automatically included reviewers for sensitive paths among the security basics.
The fine-tuning for new pushes is important as well: an iteration is a new version of the pull request after a further commit. If approvals have to be reassessed after a new iteration, old review does not simply continue to count silently.
How do I fit AI review into my process without making the merge depend on it?
Treat it as an additional signal. For Azure Repos, Microsoft describes a Comment review in “Review pull requests”, accessed on 01/11/2026, not an approval. AI review therefore makes more sense for hints about patterns, unusual areas and follow-up questions than for actually taking responsibility in the review.
Whether robust metrics will be available for this later belongs on a page with later measurements, not in the checklist itself.
What should I check in advance for data paths and internal responsibilities?
Before introducing it, clarify what content is processed, where processing may take place and which roles are involved. For data protection, DORA, NIS2 and co-determination, you should review the issue with a lawyer and your data protection officer.
If you want to follow the status of a service that is in development, public changes are helpful. Information on planned self-service, subscription quotas and the status “in development, not yet available” can be found on the preliminary overview page.
Next step
Set the checklist as a fixed review definition for your team: short, clear and applicable in the same way to every change. What matters is not the length, but that before a pull request is completed it is clear what must have been checked and what remains guidance only.
In practice, this separation helps:
- mandatory points for every pull request,
- optional guidance depending on risk,
- exceptions only with justification in the pull request.
This keeps the review understandable, even when several people are involved.
If you want to follow the topic further: Polier by ballmüller solutions, Berlin, is in development and was not yet available on 01/11/2026.