Java Code Review Checklist

Code Review Overview

graph TB
    Review[Code Review Checklist] --> Categories[6 Main Categories]
    
    Categories --> C1[Functionality<br/>Design & Architecture]
    Categories --> C2[Clean Code<br/>Readability]
    Categories --> C3[Fundamentals<br/>Java Basics]
    Categories --> C4[Security<br/>Data Protection]
    Categories --> C5[Performance<br/>Efficiency]
    Categories --> C6[Testing<br/>Quality Assurance]
    
    style Review fill:#FF9900

Interview Question: "How would you evaluate code quality of others' work?"

Systematic Approach:

• Organized into six critical categories covering all aspects of code quality
• Each category addresses specific concerns from high-level design to low-level implementation
• Use this framework in interviews to demonstrate comprehensive evaluation skills
• Helps identify issues early and maintain consistency across codebase
• Ensures adherence to best practices and industry standards
• Regular application leads to maintainable, secure, and performant applications
• Provides common vocabulary for team discussions about code quality

1. Functionality & Design

graph TB
    Functionality[Functionality Review] --> Principles[Design Principles]
    
    Principles --> SOLID[SOLID Principles]
    SOLID --> S[Single Responsibility]
    SOLID --> O[Open/Closed]
    SOLID --> L[Liskov Substitution]
    SOLID --> I[Interface Segregation]
    SOLID --> D[Dependency Inversion]
    
    Principles --> DRY[DRY<br/>Don't Repeat Yourself]
    Principles --> KISS[KISS<br/>Keep It Simple]
    
    Functionality --> OOP[OOP - APIE]
    OOP --> A[Abstraction]
    OOP --> P[Polymorphism]
    OOP --> I2[Inheritance]
    OOP --> E[Encapsulation]
    
    style SOLID fill:#4CAF50

Design Quality Checklist:

• SOLID Principles: Classes have single responsibilities, open for extension but closed for modification
• Depend on abstractions rather than concrete implementations
• DRY: Eliminate code duplication to reduce maintenance burden and bug potential
• KISS: Advocate simplicity over complexity for easier understanding and modification
• OOP Concepts (APIE): Foundation for well-structured object-oriented design
• Low Coupling: Minimal dependencies between components for flexibility
• High Cohesion: Related functionality grouped together for maintainability
• Apply functional programming paradigm where it makes sense
• Simple, maintainable, and reusable implementation

2. Clean Code - Naming & Structure

graph TB
    Clean[Clean Code] --> Naming[Meaningful Names]
    Clean --> Structure[Code Structure]
    
    Naming --> Good[✓ Good Examples]
    Good --> G1[calculateGst amount]
    Good --> G2[List users]
    Good --> G3[CustomerDao.java]
    
    Naming --> Bad[✗ Bad Examples]
    Bad --> B1[List list]
    Bad --> B2[tmp, x, data]
    
    Structure --> Small[Small Functions]
    Structure --> Single[Single Purpose]
    Structure --> NoDup[No Duplication]
    
    style Good fill:#C8E6C9
    style Bad fill:#FFCDD2

Clean Code Principles:

• Descriptive Names: Variables and methods clearly communicate intent without comments
• Example: calculateGst(amount) is self-documenting, calc(x) requires mental translation
• Small Classes/Functions: Each focused on single responsibility
• CustomerDao handles only data access, not business logic or validation
• Separation of Concerns: Makes code easier to test, modify, and understand
• Avoid Generic Names: No list, data, or tmp that provide no context
• Remove Dead Code: Commented-out code and unused variables—version control preserves history
• Proper Logging: Use slf4j/logback instead of System.out.println statements
• Standard Formatting: Share formatting template across development team

3. Function Parameters Best Practice

graph LR
    subgraph Bad[❌ Bad: 6+ Parameters]
        BadFunc[processOrder<br/>customerCode<br/>customerName<br/>address<br/>price<br/>quantity<br/>discount]
    end
    
    subgraph Good[✅ Good: Value Objects]
        GoodFunc[processOrder<br/>customer<br/>order]
        Customer[CustomerDetail]
        Order[OrderDetail]
    end
    
    GoodFunc --> Customer
    GoodFunc --> Order
    
    style Bad fill:#FFCDD2
    style Good fill:#C8E6C9

Parameter Management:

• Problem: Many parameters increase cognitive load and error likelihood
• Each parameter makes function harder to understand, test, and maintain
• Risk of passing arguments in wrong order increases with parameter count
• Solution: Group related parameters into value objects or DTOs
• Instead of six parameters, pass two objects: CustomerDetail and OrderDetail
• Benefits: Improved readability, easier validation, better encapsulation
• Value objects can include validation logic and default values
• Maintainability: Add new fields by modifying object, not every function signature
• Especially important for public APIs where backward compatibility matters

4. Java Fundamentals

graph TB
    Fund[Java Fundamentals] --> Immut[Immutability]
    Fund --> Access[Access Control]
    Fund --> Types[Data Types]
    
    Immut --> Final[Final Classes]
    Immut --> ThreadSafe[Thread-Safe]
    Immut --> Example[String class]
    
    Access --> Private[private]
    Access --> Protected[protected]
    Access --> Public[public]
    
    Types --> Interface[Code to Interface]
    Types --> BigDecimal[BigDecimal for Money]
    Types --> Enums[Enums vs Constants]
    
    style Immut fill:#4CAF50

Fundamental Best Practices:

• Immutability: Objects inherently thread-safe and more secure once created
• String class exemplifies this—every operation returns new String
• Make classes final when inheritance isn't needed to prevent unintended extension
• Access Control: Enforce encapsulation by limiting visibility (private, protected, public)
• Code to Interfaces: Use List vs ArrayList for flexibility and testability
• BigDecimal: Use for monetary calculations to avoid floating-point precision errors
• Enums: Prefer over integer constants for type safety and readability
• Override Methods: Correctly implement equals(), hashCode(), and toString()
• Fail-Fast: Validate input parameters early to catch errors at boundary
• Equals-hashCode contract is critical for collections

5. Security Checklist

graph TB
    Security[Security] --> Data[Data Protection]
    Security --> Input[Input Validation]
    Security --> Resources[Resources]
    
    Data --> NoLog[No Sensitive Logs]
    Data --> Encrypt[Encrypt Passwords]
    Data --> Immutable[Immutable Objects]
    
    Input --> Sanitize[Sanitize Inputs]
    Input --> Prepared[Prepared Statements]
    Input --> Validate[Validate All]
    
    Resources --> Release[Release Connections]
    Resources --> DoS[Prevent DoS]
    
    style Security fill:#FF5252

Security Requirements:

• Data Protection: Never log sensitive data (passwords, credit cards, personal info)
• Logs often stored insecurely and accessible to many people
• Encrypt sensitive data at rest and in transit using industry-standard algorithms
• Input Validation: Sanitize all user inputs to prevent injection attacks
• Never trust client-side validation alone
• Use prepared statements for database queries to prevent SQL injection
• Validate inputs against expected formats, ranges, and types
• Resource Management: Release resources in finally blocks or try-with-resources
• Prevents resource exhaustion and denial-of-service attacks
• Error Handling: Don't expose internal details (file paths, server names) in error messages
• Authentication/Authorization: Implement proper access controls and use SSL/TLS
• Follow principle of least privilege—grant only necessary permissions

6. Performance & Concurrency

graph TB
    Perf[Performance] --> Concur[Concurrency]
    Perf --> Memory[Memory]
    Perf --> Optimize[Optimization]
    
    Concur --> ThreadSafe[Thread-Safe Code]
    Concur --> Sync[Small Sync Blocks]
    Concur --> Libraries[Concurrency Utils]
    
    Memory --> Reuse[Reuse Objects]
    Memory --> LongLived[Watch ThreadLocal]
    Memory --> NoLeak[Prevent Leaks]
    
    Optimize --> SQL[Efficient SQL]
    Optimize --> Algorithms[Good Algorithms]
    
    style Concur fill:#2196F3

Performance Best Practices:

• Thread Safety: Write thread-safe code using proper synchronization and immutable objects
• Use concurrent collections (ConcurrentHashMap, CopyOnWriteArrayList)
• Synchronization: Keep synchronized blocks small to minimize contention
• Synchronizing entire methods is often excessive
• Concurrency Utilities: Use java.util.concurrent (ExecutorService, atomic classes)
• Prefer utilities over manual synchronization
• Memory Management: Watch for leaks from long-lived objects holding short-lived references
• ThreadLocal and static variables are common culprits
• Object Reuse: Use object pooling or flyweight pattern for expensive objects
• Optimization: Profile before optimizing—optimize frequently-executed code paths
• Efficient SQL: Avoid Cartesian joins and N+1 problems
• Algorithms: Use appropriate data structures—O(n²) vs O(n log n) matters at scale

7. Testing Best Practices

graph TB
    Test[Testing] --> Coverage[Coverage]
    Test --> Quality[Quality]
    Test --> Independent[Independence]
    
    Coverage --> Unit[Unit Tests]
    Coverage --> Negative[Negative Cases]
    Coverage --> Exceptions[Exception Tests]
    
    Quality --> OneUnit[One Unit]
    Quality --> Mock[Mock Objects]
    Quality --> NoTry[No try-catch]
    
    Independent --> RunAny[Any Order]
    Independent --> NoState[No State]
    Independent --> Simple[Simple Setup]
    
    style Test fill:#4CAF50

Testing Requirements:

• Coverage: Aim for 80%+ unit test coverage, but focus on meaningful tests
• Don't just chase coverage numbers—test critical paths and edge cases
• Unit Testing: Test one unit at a time—if testing service, mock the DAO
• If testing DAO, mock the database
• Negative Scenarios: Test null inputs, empty collections, boundary conditions, exceptions
• Independence: Tests must run in any order without affecting each other
• Avoid state dependencies between tests—each test sets up its own data
• Mock Objects: Isolate external dependencies (databases, file systems, network services)
• Test Structure: Don't use try-catch in tests—declare throws Exception
• Avoid System.out.println—use proper assertions
• Simple Setup: Complex setup indicates code under test may be too complex
• Start testing functions with fewest dependencies, work up to complex ones

8. Code Review Process

sequenceDiagram
    participant Dev as Developer
    participant PR as Pull Request
    participant CI as CI/CD
    participant Rev as Reviewer
    
    Dev->>PR: Submit Code
    PR->>CI: Trigger Build
    CI->>CI: Run Tests
    CI->>CI: Check Coverage
    CI->>CI: Static Analysis
    CI-->>PR: ✓ Pass
    
    PR->>Rev: Request Review
    Rev->>Rev: Apply Checklist
    Rev->>PR: Provide Feedback
    
    alt Approved
        PR->>CI: Merge
    else Changes Needed
        PR->>Dev: Request Changes
    end

Review Process:

• Automated Checks: CI/CD runs unit tests, measures coverage, performs static analysis
• Catches obvious issues early and ensures baseline quality before human review
• Manual Review: Reviewer applies this checklist systematically
• Examines functionality, clean code, fundamentals, security, performance, testing
• Constructive Feedback: Explain why something should change, not just what
• Be specific and educational in comments
• Consistency: Use checklist to ensure consistency across reviews
• Avoid missing critical issues by following systematic approach
• Prioritization: Balance thoroughness with pragmatism
• Prioritize security vulnerabilities and bugs over style preferences
• Culture: Foster collaborative improvement, not criticism
• Code review is learning opportunity for both reviewer and author