Keep Code Left: The Art of Readable Logic

Question

In 2015, while working at Software Andina, I had the privilege of attending a session that changed the way I look at a source file. At the time, we were frequently visited by developers from the United States who shared their expertise to help us sharpen our craft.

One of those visitors was Mick Andrew, a seasoned developer and Director of Development at Sage. He was a close friend of my boss at the time, John Rutherfurd, and he brought with him a presentation titled "Keep Code Left" (KCL).

The title was deceptively simple, but the philosophy behind it was profound. As developers, we often focus on making code work, but we frequently forget that code is read far more often than it is written. Mick taught us that by following a few "cookbook" rules, we could transform convoluted, deeply nested logic into something clean, linear, and remarkably easy to maintain.
What is Keep Code Left?

At its core, Keep Code Left is a coding style designed to maximize readability. The name refers to the visual structure of the code: the more your logic is indented (pushed to the right), the harder it becomes for a human brain to track the "state" and the flow of the program.

The goals of KCL are straightforward:

Simplify Logic: Create code that flows linearly rather than branching out.

Enhance Readability: Allow developers to "see the flow" and grasp the goal of a method at a glance.

Reduce Maintenance Bugs: Simple code is harder to break during future updates.

Streamline Reviews: It provides a standard that can be verified during code reviews without needing deep domain knowledge.

Since that day in 2015, I have applied these rules to nearly every project I’ve touched. In this post, I’ll break down exactly how to "Keep Code Left" and why your future self (and your team) will thank you for it.

Why “Keep Code Left” Matters
When code becomes deeply nested, several problems appear:

• Harder to read line-by-line
• Logic becomes difficult to follow
• Increased risk of bugs
• Slower code reviews

KCL aims to:

• Simplify logic
• Reduce indentation
• Make flow visible at a glance
• Enable faster and more reliable reviews

The Core Principle

Avoid unnecessary nesting. Prefer early exits and linear flow.

Instead of wrapping logic inside multiple if blocks, you handle edge cases early and return immediately.

Example 1: Nested Code (Bad)

public void ProcessOrder(Order order)
{
    if (order != null)
    {
        if (order.IsValid())
        {
            if (order.Items.Count > 0)
            {
                // Process order
                Save(order);
            }
        }
    }
}

Problems:

• 3 levels of nesting
• Hard to scan quickly
• Main logic is buried

Example 1: Keep Code Left (Better)

public void ProcessOrder(Order order)
{
    if (order == null) return;
    if (!order.IsValid()) return;
    if (order.Items.Count == 0) return;

    // Process order
    Save(order);
}

Benefits:

• Flat structure
• Easy to read top-to-bottom
• Main logic is immediately visible

Example 2: Conditional Complexity
Bad Approach

if (user) {
    if (user.isActive) {
        if (!user.isBlocked) {
            sendEmail(user);
        }
    }
}

KCL Approach

if (!user) return;
if (!user.isActive) return;
if (user.isBlocked) return;

sendEmail(user);

**Key Techniques of Keep Code Left

1. Early Returns
   **
   Handle invalid cases first:

def process(data):
    if data is None:
        return

2. Guard Clauses

Protect your logic from bad inputs:

if (user == null) return;
if (!user.hasPermission()) return;

3. Reduce Indentation

Every level of indentation increases cognitive load.

Bad:

if (a)
{
    if (b)
    {
        if (c)
        {
            DoSomething();
        }
    }
}

Better:

if (!a || !b || !c) return;

DoSomething();

4. Focus on the “Happy Path”

The main logic should be:

• Straightforward
• Easy to locate
• Not buried inside conditions

Impact on Code Reviews

KCL is extremely effective in reviews because:

• Patterns are easy to detect
• Less domain knowledge is required
• Reviewers can quickly spot:
• Missing checks
• Logical errors
• Anti-patterns

Mental Model
When writing code, ask:

• Can I exit earlier?
• Can I reduce one level of indentation?
• Is the main logic immediately visible?

Real-World Benefit

Over time, applying KCL leads to:

• Fewer bugs
• Faster onboarding of new developers
• Cleaner diffs in pull requests
• More maintainable systems

Keep Code Left (KCL) Guidelines for AI
Applying Keep Code Left (KCL) principles when working with AI assistants is important because, by default, they tend to generate code that is correct but unnecessarily nested. This makes the code harder to read, review, and maintain over time. By explicitly enforcing simple rules like early returns and minimal indentation, you guide the AI to produce cleaner, more linear code that aligns better with how humans understand logic. This reduces cognitive load, speeds up code reviews, and improves long-term maintainability.

Claude.MD Example:

Example: Claude .md

md
## KCL Rules
- Use early returns
- Avoid nested if statements
- Keep code flat and readable

### Example

Bad:
if (user) {
    if (user.isActive) {
        process(user);
    }
}

Good:
if (!user) return;
if (!user.isActive) return;

process(user);