TL;DR: When you focus code reviews on syntax, you miss architecture, security, design and intent.

Problems in view 😔

Suggested solutions 😃

  1. Leave the boring work to the IA
  2. Automate style checks
  3. Review architecture first
  4. Discuss intent early with technical analysis and control points
  5. Enforce review roles
  6. Raise abstraction level

Refactorings ⚙️

HACKERNOONRefactoring 032 - Apply Consistent Style Rules | HackerNoonWhen machines generate large amounts of code, you need to apply one consistent style to all files.


HACKERNOONRefactoring 016 - Building With The Essence | HackerNoonPass essential attributes during object creation to reduce mutability and eliminate getters and setters.

Context 💬

When you review code, you choose where to spend your valuable human attention.

When you spend that attention on commas, naming trivia, or formatting, you ignore the parts that matter.

This smell appears when teams confuse cleanliness with correctness. Syntax looks clean. Architecture rots.

Sample Code 📖

Wrong ❌

<?php

class UserRepository {
    public function find($id){
        $conn = mysqli_connect(
             "localhost", // Pull Request comment - Bad indentation
            "root",
            "password123",
            "app"
        );

        $query = "Select * FROM users WHERE id = $id";
        // Pull Request comment - SELECT should be uppercase
        return mysqli_query($conn, $query);
    }
}

Right 👉

<?php

final class UserRepository {
    private Database $database;

    public function __construct(Database $database) {
        $this->database = $database;
    }

    public function find(UserId $id): User {
        return $this->database->fetchUser($id);
    }
}

// You removed credentials, SQL, and infrastructure noise.
// Now reviewers can discuss design and behavior.

Detection 🔍

[X] Manual

You can detect this smell by examining pull request comments.


When you see multiple comments about formatting, indentation, trailing commas, or variable naming conventions, you lack proper automation.


Check your continuos integration pipeline configuration. If you don't enforce linting and formatting before human review, you force reviewers to catch these issues manually.


Review your code review metrics. If you spend more time discussing style than architecture, you have this smell.

Automated tools like SonarQube, ESLint, and Prettier can identify when you don't enforce rules automatically.

Tags 🏷️

Level 🔋

[x] Intermediate

Why the Bijection Is Important 🗺️

Code review represents the quality assurance process in the MAPPER.


When you break the bijection by having humans perform mechanical checks instead of judgment-based evaluation, you mismodel the review process.


You no longer validate whether the concepts, rules, and constraints match the domain.

You only validate formatting.


That gap creates systems that look clean and behave wrong.

The broken bijection manifests as reviewer fatigue and missed bugs. You restore proper mapping by separating mechanical verification (automated) from architectural review (human).

AI Generation 🤖

AI generators often create this smell.

They produce syntactically correct code with weak boundaries and unclear intent.

AI Detection 🧲

AI can reduce this smell when you instruct it to focus on architecture, invariants, and risks instead of formatting.

Give them clear prompts and describe the role and skills of the reviewer.


Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Find real problems in the code beyond nitpicking, review this code focusing on architecture, responsibilities, security risks, and domain alignment. Ignore formatting and style.

Steal My Prompts (Without Proper Instructions) 📵

Steal My Prompts (With Specific Instructions) 👩‍🏫

Conclusion 🏁

Code reviews should improve systems, not satisfy linters.

When you automate syntax, you free humans to think.

That shift turns reviews into real design conversations.

https://hackernoon.com/code-smell-06-trying-to-be-a-clever-programmer

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj

https://hackernoon.com/code-smell-05-comment-abusers

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxv

https://hackernoon.com/code-smell-236-what-to-do-with-excessively-long-code-lines


Disclaimer: Code Smells are my opinion.

Credits: Photo by Portuguese Gravity on Unsplash

Design is about intent, not syntax.

Grady Booch

HACKERNOON400+ Thought-Provoking Software Engineering Quotes | HackerNoonThe most complete curated collection of software and programming quotes


This article is part of the CodeSmell Series.

HACKERNOONHow to Find the Stinky Parts of Your Code (Part I) | HackerNoonThe code smells bad. Let’s see how to change the aromas. In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most of these smells are just hints of something that might be wrong. They are not rigid rules.