no-lonely-if

📡 Live from GitHub — This documentation is fetched directly from no-lonely-if.md and cached for 6 hours.

Keywords: if, else, refactoring, readability, ESLint rule, code quality, LLM-optimized

Disallow if statements as the only statement in else blocks

Disallow if statements as the only statement in else blocks. This rule is part of eslint-plugin-maintainability.

Quick Summary

Aspect	Details
Severity	Warning (code quality)
Auto-Fix	✅ Yes (converts to else if)
Category	Quality
ESLint MCP	✅ Optimized for ESLint MCP integration
Best For	Code readability, reducing nesting

Rule Details

A "lonely if" occurs when an if statement is the only statement inside an else block. This can be simplified to else if.

Why This Matters

Issue	Impact	Solution
📖 Readability	Unnecessary nesting	Use else if
🔍 Code Review	Extra indentation to parse	Flatten structure
📏 Line Length	Wasted horizontal space	Simplify

Examples

❌ Incorrect

if (condition1) {
  doSomething();
} else {
  if (condition2) {
    // Lonely if
    doSomethingElse();
  }
}

// Deeply nested
if (a) {
  // ...
} else {
  if (b) {
    // ...
  } else {
    if (c) {
      // Multiple lonely ifs
      // ...
    }
  }
}

✅ Correct

if (condition1) {
  doSomething();
} else if (condition2) {
  doSomethingElse();
}

// Cleaner chain
if (a) {
  // ...
} else if (b) {
  // ...
} else if (c) {
  // ...
}

Configuration Examples

Basic Usage

{
  rules: {
    'maintainability/no-lonely-if': 'warn'
  }
}

no-nested-ternary - Prevents nested ternaries
cognitive-complexity - Complexity limits

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Dynamic Variable References

Why: Static analysis cannot trace values stored in variables or passed through function parameters.

// ❌ NOT DETECTED - Value from variable
const value = externalSource();
processValue(value); // Variable origin not tracked

Mitigation: Implement runtime validation and review code manually. Consider using TypeScript branded types for validated inputs.

Wrapped or Aliased Functions

Why: Custom wrapper functions or aliased methods are not recognized by the rule.

// ❌ NOT DETECTED - Custom wrapper
function myWrapper(data) {
  return internalApi(data); // Wrapper not analyzed
}
myWrapper(unsafeInput);

Mitigation: Apply this rule's principles to wrapper function implementations. Avoid aliasing security-sensitive functions.

Imported Values

Why: When values come from imports, the rule cannot analyze their origin or construction.

// ❌ NOT DETECTED - Value from import
import { getValue } from './helpers';
processValue(getValue()); // Cross-file not tracked

Mitigation: Ensure imported values follow the same constraints. Use TypeScript for type safety.