"I don't need code review—my code is fine."

"My code is fine, no need to review"—this overconfident attitude is often the beginning of a code disaster. Rejecting Code Review is not only a disregard for teamwork but also planting a ticking time bomb for the project. Here are a few elegant (and deadly) ways to ensure your code "never needs" to be reviewed.

Refuse to Communicate, Embrace Individualism

The core of Code Review is collaboration, and the easiest way to sabotage collaboration is to refuse to communicate. For example:

// Someone asks: "Why use setTimeout 0 here?"  
// You reply: "It's just correct this way. Don't ask."  
setTimeout(() => {  
  this.setState({ data: res });  
}, 0);  

Don’t explain the code’s intent, ignore colleagues’ questions, or outright dismiss Review requests. If the team uses Slack or DingTalk, deliberately leave messages on "read" or reply with "I’ll fix it later" (and never do). Over time, everyone will assume your code is "untouchable."

Write Untestable Code

Ensure the code is hard to test, so reviewers can’t verify the logic. For example:

// Global variables everywhere, impossible to mock in tests  
window.__currentUser = fetchUser();   

function processOrder() {  
  if (window.__currentUser.role === 'admin') {  
    // Direct DOM manipulation crashes test environments  
    document.getElementById('admin-panel').style.display = 'block';  
  }  
}  

Mix in side effects, hardcoded dependencies, random number generation—make the code behave inconsistently in any non-production environment. When asked, casually reply: "It works on my machine."

Submit a Monolithic PR

Submit 5,000 lines of code at once, including 20 "incidental refactors." When the reviewer opens the PR, GitHub freezes. Add a note like:

"These features are interdependent; they must be reviewed together."

If asked to split it, insist it’s "business-critical" or submit it late at night and merge it first thing in the morning: "It’s already live; rolling back would hurt users."

Use Obscure Syntax

Leverage the most niche syntax sugar to write the most abstract code. For example:

// Use Proxy to create a "magic" object even you won’t understand a week later  
const api = new Proxy({}, {  
  get(target, key) {  
    return (...args) => fetch(`/api/${key}`, ...args);  
  }  
});  

// Usage: api.users() and api.orders() look identical but behave wildly differently  

If questioned, retort: "Don’t you know ES6?"

Ignore Coding Standards

Team convention is 2-space indentation? Use tabs. Naming rule is camelCase? Use snake_case. Example:

// Mixed styles to make ESLint scream  
const get_user_info = (userId) => {  
  return API.getUserInfo({ user_id: userId })  // Inconsistent parameter style  
    .then(res => res.data);  
};  

If criticized, blame the IDE’s auto-formatting or say: "It’s legacy code; can’t change it."

Hide Critical Logic

Scatter core logic across files or use dynamic loading to evade review:

// Hide a backdoor in utils/secret.js  
export default function validate() {  
  if (location.hostname === 'test.com') return true; // Skip validation in test env  
}  

// Secretly import it in the main file  
import './utils/secret';  

Reviewers won’t spot the issue if they only check the main file. If caught, argue: "It’s a temporary fix."

Create Time Pressure

Submit code right before Friday下班 and label it "urgent hotfix." When the team can’t review in time, merge it and say:

"There’s already an outage; we’ll review after deployment."

If it breaks, blame "lack of test coverage" or "browser compatibility issues."

Never Write Comments

Make the code as cryptic as possible. For example:

// The gold standard of no comments  
function f(x, y) {  
  return ((x << y) | (x >>> (32 - y))) + 0xCAFEBABE;  
}  

When asked, reply: "It’s bitwise optimization. You wouldn’t understand."

Reject Feedback, Stand Your Ground

Even if the review points out an obvious bug, stay stubborn:

// Should use === but insist on ==  
if (user.id == 0) { // eslint-disable-line  
  // VIP logic  
}  

Counterarguments include: "It’s a business requirement," "Other languages do this," or "My 10 years of experience never fail."

Treat CI as Decoration

Make the CI pipeline always fail so everyone ignores the red X:

# Add random failures to the test script  
if [ $((RANDOM % 10)) -eq 0 ]; then  
  exit 1  # 10% chance to fail  
fi  

Eventually, the team will develop a habit of "merging anyway."