indent

What it does

indent reformats C source code according to a configurable style — controlling indentation width, brace placement, spacing around operators, and comment alignment — without changing the program's behavior. It supports several named style presets (GNU, K&R, original Berkeley/BSD) selectable with a single flag, plus many fine-grained options for customizing exact formatting rules. It's one of the older members of the C formatting toolchain; for many projects today, especially those mixing C and C++, the more actively developed clang-format has become the default choice, though indent remains packaged and functional on current distributions for straightforward C formatting needs.

Beginner examples

• indent myfile.c — reformat a file in place using the default GNU style
• indent -kr myfile.c — reformat using Kernighan & Ritchie style
• indent -bsd myfile.c — reformat using original Berkeley/BSD style
• indent myfile.c -o myfile.formatted.c — write the result to a new file instead of overwriting the original

indent -kr -i4 myfile.c

Advanced examples

• Reformat an entire project's C files in place: find . -name "*.c" -exec indent {} \;
• Combine explicit style flags for fine-grained control beyond a named preset: indent -kr -i4 -nut -br myfile.c (K&R style, 4-space indent, spaces not tabs, braces on same line as control statements)
• Store team-wide formatting rules in a .indent.pro file in the project root so every invocation of indent in that directory picks up the same settings automatically.
• Preview changes before overwriting by diffing: indent myfile.c -o /tmp/preview.c && diff myfile.c /tmp/preview.c

find src/ -name "*.c" -o -name "*.h" | xargs indent -kr -i4

Common mistakes

• Running indent in place on a file with uncommitted, unreviewed changes and losing track of what the tool actually altered — always run it on a clean git working tree so the diff is easy to review afterward.
• Mixing indent and clang-format on the same codebase without agreeing on one as the canonical formatter, causing files to bounce between two slightly different styles every time a different contributor formats them.
• Assuming indent's named styles (GNU, K&R, BSD) match a team's exact preferred style out of the box — they're close starting points, not guarantees; fine-tune with additional flags or a .indent.pro file.
• Forgetting indent is C-oriented; running it directly on C++ files can mishandle constructs like templates or namespaces that didn't exist when the tool was designed.

Tips

• Commit an .indent.pro file to the repository root so every contributor's indent invocation uses the same style automatically.
• Run indent on a clean git working tree so you can review its changes as an isolated diff before committing.
• For mixed C/C++ codebases, consider standardizing on clang-format instead, since indent is not designed with C++-specific syntax in mind.
• Use -o to preview reformatting into a separate file before committing to modifying files in place.

Best practices

• Pick one formatter for a given codebase — either indent or clang-format — and apply it consistently via a pre-commit hook or CI check, rather than letting contributors use whichever tool they personally prefer.
• Check in a shared style configuration (.indent.pro) so formatting is deterministic and doesn't depend on each developer's local defaults.
• Run indent (or any reformatter) as an isolated commit separate from logic changes, so reviewers can distinguish formatting-only diffs from functional ones.
• For new C++ projects, prefer clang-format, which has broader language support and more active maintenance than indent.

Real-world use cases

• Normalizing formatting across an older C codebase that predates any enforced style guide.
• Enforcing a consistent style in a project that intentionally favors GNU or K&R conventions, where indent's named presets map directly to the desired style.
• Cleaning up whitespace and brace-placement inconsistencies before a code review, so reviewers can focus on logic instead of style nits.
• Preparing legacy vendor C source for inclusion in a project with a house style, by running it through indent with the project's chosen preset.

Common interview questions

• What does indent actually change in source code? Only whitespace, indentation, brace placement, and spacing conventions — it doesn't alter the program's parsed meaning or behavior.
• How does indent compare to clang-format? indent is older and C-specific, with named style presets and command-line flags; clang-format is newer, supports both C and C++, uses a more flexible YAML configuration, and has wider adoption in modern projects, though indent remains available and functional for basic C formatting.
• How would you enforce a consistent style across a team using indent? Commit a shared .indent.pro options file to the repository so every invocation picks up the same settings, and run it via a pre-commit hook or CI check rather than relying on manual, ad hoc formatting.
• Why might you avoid running indent directly on C++ code? Because it was designed for C and may not correctly handle C++-specific syntax like templates, namespaces, or operator overloading, potentially producing incorrect or ugly formatting.