---
applyTo: lldb/**/*
---

When reviewing code, focus on:

## Language, Libraries & Standards

- Target C++17 and avoid vendor-specific extensions.
- For Python scripts, follow PEP 8.
- Prefer standard library or LLVM support libraries instead of reinventing data structures.

## Comments & Documentation

- Each source file should include the standard LLVM file header.
- Header files must have proper header guards.
- Non-trivial classes and public methods should have Doxygen documentation.
- Use `//` or `///` comments normally; avoid block comments unless necessary.
- Non-trivial code should have comments explaining what it does and why. Avoid comments that explain how it does it at a micro level.

## Language & Compiler Issues

- Write portable code; wrap non-portable code in interfaces.
- Do not use RTTI or exceptions.
- Prefer C++-style casts over C-style casts.
- Do not use static constructors.
- Use `class` or `struct` consistently; `struct` only for all-public data.
- When then same class is declared or defined multiple times, make sure it's consistently done using either `class` or `struct`.

## Headers & Library Layering

- Include order: module header → local/private headers → project headers → system headers.
- Headers must compile standalone (include all dependencies).
- Maintain proper library layering; avoid circular dependencies.
- Include minimally; use forward declarations where possible.
- Keep internal headers private to modules.
- Use full namespace qualifiers for out-of-line definitions.

## Control Flow & Structure

- Prefer early exits over deep nesting.
- Do not use `else` after `return`, `continue`, `break`, or `goto`.
- Encapsulate loops that compute predicates into helper functions.

## Naming

- LLDB's code style differs from LLVM's coding style.
- Variables are `snake_case`.
- Functions and methods are `UpperCamelCase`.
- Static, global and member variables have `s_`, `g_` and `m_` prefixes respectively.

## General Guidelines

- Use `assert` liberally; prefer `llvm_unreachable` for unreachable states.
- Do not use `using namespace std;` in headers.
- Provide a virtual method anchor for classes defined in headers.
- Do not use default labels in fully covered switches over enumerations.
- Use range-based for loops wherever possible.
- Capture `end()` outside loops if not using range-based iteration.
- Including `<iostream>` is forbidded. Use LLVM’s `raw_ostream` instead.
- Don’t use `inline` when defining a function in a class definition.

## Microscopic Details

- Preserve existing style in modified code.
- Prefer pre-increment (`++i`) when value is unused.
- Use `private`, `protected`, or `public` keyword as appropriate to restrict class member visibility.
- Omit braces for single-statement `if`, `else`, `while`, `for` unless needed.

## Review Style

- Be specific and actionable in feedback.
- Explain the "why" behind recommendations.
- Link back to the LLVM Coding Standards: https://llvm.org/docs/CodingStandards.html.
- Ask clarifying questions when code intent is unclear.

Ignore formatting and assume that's handled by external tools like `clang-format` and `black`.
Remember that these standards are **guidelines**.
Always prioritize consistency with the style that is already being used by the surrounding code.