Code Review Guidelines - Backend (Django)

This document contains backend-specific code review rules for Django/Python development.

Refer to General Guidelines for general review process, SLAs, and reviewer assignment rules.

Part 1: Developer Self-Review (Before Creating PR)

Step 1: Run Pre-commit Hooks on Changed Files

# Run on staged files only
pre-commit run

# Or run on specific changed files
pre-commit run --files $(git diff --name-only HEAD)

# Or run on files changed vs main/develop branch
pre-commit run --files $(git diff --name-only origin/develop)

Step 2: AI-Assisted Self-Review

In VS Code/Cursor, select your changed files and use one of these prompts:

Quick Review Prompt:

Review this code against our backend_development.mdc standards. 
Check for: BaseModel inheritance, ValidationError usage, mapper patterns, 
QuerySet optimization, naming conventions, and response format compliance.
Flag any violations as CRITICAL, MAJOR, or MINOR.

Comprehensive Review Prompt:

Perform a thorough code review of my changes using @backend_development.mdc rules.

Check these categories:
1. CODE QUALITY: snake_case naming, no nested ternaries, f-strings, blank line before return
2. ARCHITECTURE: BaseModel/GenericView inheritance, prepare_urls usage, serializer location
3. SECURITY: @allow_guest usage, permission checks, no hardcoded secrets
4. PERFORMANCE: select_related/prefetch_related, no N+1, cache-aware methods
5. PATTERNS: Model.get() not objects.get(), mapper dicts not if/else, ValidationError raised

For each issue found, provide:
- Severity (CRITICAL/MAJOR/MINOR)
- Line reference
- What's wrong
- How to fix it

Step 3: Fix All Issues Before PR

AI Severity	Action Required
CRITICAL	Must fix - PR will be rejected
MAJOR	Must fix - Blocks approval
MINOR	Should fix - Reviewer will request

Part 2: Backend Pre-Submission Checklist

#	Check	Verification
1	Pre-commit hooks pass	Run `pre-commit run` - must show all green
2	Self-review completed	AI review + manual diff review
3	No debug code	Remove `print()`, `breakpoint()`, commented code
4	Migrations reviewed	Check generated migration matches intent, no data migrations
5	Documentation updated	Docstrings for new classes/complex methods
6	Fixtures updated	Update fixture files if adding new master data (see below)

Fixture File Updates (Mandatory)

If your changes involve adding new entries to tables with fixtures, you MUST update the corresponding fixture file in fixtures/ directory:

Change Type	Fixture File to Update
New activity log master category	`master_log_category.json`
New activity log sub-category	`sub_log_category.json`
New communication trigger	`communication_triggers.json`
New communication variable	`communication_variable.json`
New center feature	`center_feature_list.json`
New assistant prompt	`assistant_prompt.json`

⚠️ Failure to update fixtures will cause issues in fresh deployments and new environments.

Part 3: Reviewer Checklist - Code Quality (Blocking)

Check	Standard Reference
✅ Follows `snake_case` for variables/functions, `PascalCase` for classes	Naming Conventions
✅ No nested ternaries	Core Principles
✅ Uses `Model.get()` instead of `objects.get()`	BaseModel Pattern
✅ Uses mapper dictionaries instead of if/else chains	Configuration Mappers
✅ `ValidationError` raised (not returned) with proper status codes	Error Handling
✅ `JsonResponse` with consistent structure (`status`, `message`, `data`)	Response Format
✅ F-strings used for string formatting	Code Style
✅ Blank line before `return` statements	Formatting Rules

Part 4: Reviewer Checklist - Architecture Compliance (Blocking)

Check	Standard Reference
✅ Models inherit from `core.models.BaseModel`	BaseModel Pattern
✅ Views inherit from `core.view.GenericView`	View Structure
✅ Serializers inherit from `DynamicFieldsModelSerializer`	Serializers
✅ URL patterns use `prepare_urls()` utility	URL Patterns
✅ Proxy models in `{app}/proxies/` directory	Proxy Models
✅ Serializers in `{app}/serializers/` directory	Folder Structure
✅ No custom managers unless explicitly required	Custom Managers

Part 5: Reviewer Checklist - Security (Blocking)

Check	Verification
✅ `@allow_guest()` only on public endpoints	No accidental exposure
✅ `@validate_feature()` for feature-gated endpoints	Feature validation
✅ Permission checks before sensitive operations	Authorization
✅ No hardcoded secrets/credentials	Security
✅ User input validated before use	Input validation
✅ SQL injection prevention (ORM usage, no raw SQL)	Database security

Part 6: Reviewer Checklist - Performance (Blocking for High-Impact)

Check	Standard Reference
✅ `select_related()` for ForeignKey traversal	QuerySet Optimization
✅ `prefetch_related()` for reverse FK/M2M	QuerySet Optimization
✅ `.values()` / `.values_list()` when full objects not needed	QuerySet Optimization
✅ No N+1 query patterns	QuerySet Optimization
✅ Cache-aware methods used for cached models (`LabFeature.get_features()`)	Cached Model Retrieval
✅ `@transaction.atomic` for multi-step DB operations	Defensive Programming

Part 7: Reviewer Checklist - Documentation (Non-Blocking)

Check	Verification
✅ Docstrings for classes and complex methods	Documentation
✅ `category_id_mapper` defined for activity logging	Activity Logging
✅ Complex logic explained (why, not how)	Documentation

Part 8: Module Owners (Backend)

Developers MUST add the relevant module owner to their PR (Some of the module owners are):

Module/Area	Module Owner	When to Add
AI/Assistant	Sai Tharun	Any changes in `assistant/`, AI prompts, LLM integrations
Payments/Finance	Rahul Bhangale	Changes in `payments/`, `finance/`
Interfacing	Sumit Rajenimbalkar	Changes in `interfacing/`, devices, reports
Integrations	Abhijeet Mane	Changes in `integration/`
Communication	Sai Tharun	Changes in `communication/`, SMS, email
Lab Reports	Sumit Rajenimbalkar / Rahul Bhangale / Sai Tharun	Changes in `lab_reports/`
Accession	Rahul Bhangale	Changes in `accession/`
Billing	Sai Tharun	Changes in `billing/`
Insurance	Milind Naik / Sidhharth Chakraborty	Changes in `insurance/`
Bulk Registration	Sidhharth Chakraborty	Changes in `patient/`
Inventory	Subham Kumar Mal	Changes in `inventory/`
CRM	Sai Tharun / Akshay Goregankar / Ritu Kataria	Changes in `crm/`
Lab Forms	Ritu Kataria	Changes in `lab_forms/`

Important

Adding the module owner is the developer's sole responsibility.

Part 9: Backend-Specific Severity Examples

Severity	Backend Examples
🔴 Critical	Missing `@allow_guest` on auth endpoint, raw SQL with user input, exposed secrets in settings
🟠 Major	Missing `BaseModel` inheritance, N+1 queries in loops, no tests for new feature, `objects.get()` instead of `Model.get()`
🟡 Minor	Missing docstring, camelCase variable name, hardcoded string instead of constant
🔵 Suggestion	Could use `values_list()` instead of full objects, consider extracting to utility function

Backend Review Guidelines (Django)