Code Review in Java: What to Check and How to Give Feedback in Practice

Code Review in Java: What to Check and How to Give Feedback in Practice

Code Review is a systematic check of someone else's code aimed at identifying errors, improving quality, and sharing knowledge. In Java development, this is especially important due to strong typing, multithreading features, and performance requirements. However, many developers reduce reviews to a simple style check or, conversely, turn them into toxic criticism. In this article, we will break down exactly what needs to be checked in Java code and how to give feedback that is beneficial, not painful.

1. What to Check in Java Code: A Reviewer's Checklist

For a review to be effective, you need to look not only at syntax but also at architecture, security, and performance. Here are the main categories to check.

1.1 Architecture and Design

\n
• SOLID Principles: does the class violate the single responsibility principle? Is the interface turning into a "god object"?
\n
• Coupling and Cohesion: classes should be loosely coupled and have high internal cohesion.
\n
• Use of Patterns: is the use of complex patterns justified? Sometimes a simple if-else is better than a factory with a dozen classes.
\n

// Bad: class does everything at once\npublic class ReportService {\n    public void generateReport() { /* generation */ }\n    public void sendEmail() { /* sending */ }\n    public void saveToDatabase() { /* saving */ }\n}\n\n// Good: separation of concerns\npublic class ReportGenerator { ... }\npublic class EmailSender { ... }\npublic class ReportRepository { ... }\n

1.2 Exception and Error Handling

\n
• Swallowing exceptions: you must not write an empty catch (Exception e) — this hides errors.
\n
• Specificity: catch specific exceptions, not Exception or Throwable.
\n
• Logging: exceptions should be logged with sufficient context (stack trace, input data).
\n

// Bad: swallowing the exception\ntry {\n    processFile(file);\n} catch (Exception e) {\n    // do nothing\n}\n\n// Good: logging and rethrowing\ntry {\n    processFile(file);\n} catch (IOException e) {\n    log.error("Error processing file: {}", file, e);\n    throw new ProcessingException("Failed to process file", e);\n}\n

1.3 Performance and Memory

\n
• Redundant operations: creating objects in loops, unnecessary string copies via new String().
\n
• Use of Collections: is the type chosen correctly (ArrayList vs LinkedList)? Are there unnecessary synchronizations?
\n
• Stream API: does the stream impair readability? Sometimes a regular loop is clearer.
\n

// Bad: creating a string in a loop\nString result = "";\nfor (String s : list) {\n    result += s; // new string each time\n}\n\n// Good: StringBuilder\nStringBuilder sb = new StringBuilder();\nfor (String s : list) {\n    sb.append(s);\n}\n

1.4 Multithreading and Synchronization

\n
• Correct use of synchronized: is too large a block of code locked?
\n
• Concurrent collections: are you using ConcurrentHashMap instead of a hash table with external synchronization?
\n
• Deadlock risk: are resources being locked in a different order?
\n

// Deadlock risk\nsynchronized (lockA) {\n    synchronized (lockB) { ... }\n}\n// In another thread:\nsynchronized (lockB) {\n    synchronized (lockA) { ... }\n}\n

2. How to Write Code for Easy Review

A good review starts with good code. A