Code Style Checker

Style rules are agreements, not facts. A file with tab indentation is correct in a WordPress plugin and wrong in a Google Java project. This page runs the rules from published guides, names the guide behind every finding, and points at the line.

Four kinds of tool, four different questions

Teams reach for the phrase style checker to mean four things at once. They answer separate questions and run at separate moments, so knowing which one you need saves an argument in review.

Everything on this page belongs to the middle two rows. A compiler will happily accept three space indentation, a missing final newline, and a class named invoice_builder. None of it stops the build, and all of it slows down the next person reading the file.

Why the same file passes one guide and fails another

Load the JavaScript sample, run it under Airbnb, then switch to StandardJS. Errors appear and disappear without you touching a character. StandardJS drops the statement semicolon, so lines Airbnb marks as broken become correct, and the semicolons Airbnb wants become findings of their own.

Here is what each preset actually enforces.

The brace disagreement is the clearest example

Paste the same block into the Java pane and the C# pane. Google Java Style flags a brace sitting alone on a line. Microsoft flags a brace sitting at the end of a line. Two guides, two respected vendors, exactly opposite verdicts on identical code.

// Google Java Style wants this
public double total(double[] prices) {return 0;}
public double Total(double[] prices){return 0;}

Neither is better. What breaks a codebase is a file holding both, because every diff then carries brace churn from whoever last opened it.

Where the column numbers came from

The 79 in PEP 8 traces back to an 80 column terminal, minus one so a wrapped line stays visible. Linux kernel style kept 80 for the same reason. Airbnb moved to 100 once wide monitors became normal, and Black picked 88 after measuring that a slightly wider limit reduced the number of forced line breaks in real code. Modern limits protect side by side diffs and code review panes, not hardware.

Every rule the checker runs

Nothing here is hidden. These are the checks, the severity each one carries, and the pattern behind it.

Rules applied to every language

JavaScript and TypeScript

Python, PHP, Java, and C#

CSS and HTML

How the file is read before any rule runs

Naive line matching produces findings nobody wants. A URL inside a string holds a double slash, and a checker looking for comments finds one there. A comment mentioning var gets reported as a declaration. This page runs two passes before the rules see anything.

Strings and comments come out first

Every line goes through a small scanner that tracks quote state and block comment state across line boundaries. Comment text is blanked. String bodies are replaced with a filler character, so the string still occupies its columns without its contents matching anything. Block comments and Python triple quoted strings carry their state to the next line, which means a rule word inside a docstring stays quiet.

// none of these are findings
const note = "watch out for var and console.log here";const url = "https://cdn.toolexe.com/a//b";

Continuation lines are tracked by bracket depth

A running count of open parentheses and square brackets tells the checker whether a line finishes a statement or continues one. Any line sitting inside an unclosed bracket is exempt from the semicolon, indent width, and multiple space rules. This is what stops a wrapped function call from producing three findings for a single statement.

const payload = buildRequest(endpoint,{ retries: 3 },signal);

The first line opens a bracket, so the three lines under it are treated as continuation. Only the closing line is checked for its semicolon.

Where this checker gets things wrong

Read this before you file a ticket against one of its findings.

• The semicolon rule uses a heuristic, not a parser. Statement endings are decided by the last character on the line plus a short list of keyword exceptions. Unusual formatting will produce a false finding. A real parser is the only way to settle this, and one does not run here.
• Indent width ignores hanging indents. Continuation lines aligned under an opening bracket are exempt, but a hanging indent inside a chained call with no open bracket on the line will read as a broken multiple.
• Naming rules only see declarations. A badly named variable assigned without a declaration keyword passes. So does a name that is spelled consistently and means nothing.
• The quote rule checks one string per line. A line holding several strings reports once, not once per literal.
• CSS duplicate detection matches text, not meaning. Two selectors that target the same elements through different syntax are separate as far as this page is concerned.
• Guide presets are a subset, never the whole document. Airbnb runs to hundreds of rules. This page covers the formatting layer, which is the part that shows up in a diff.

What the whitespace fix touches, and what it refuses to

The Fix whitespace button rewrites four things and stops there.

1. Indentation is re-expressed at the guide's character and width. The file's own indent step is measured from its narrowest indented line, then every line is rewritten at the same nesting level. A three space Python file becomes four space, and a two space JavaScript file becomes tab indented under the WordPress preset without any line losing a level.
2. Trailing spaces and tabs are stripped from every line.
3. Runs of blank lines are collapsed to the guide maximum.
4. Blank lines at the end of the file are removed and one final newline is added.

It never reorders code, never inserts a semicolon, and never renames anything. Running it twice on the same file reports zero changes the second time, so a count of zero means the whitespace already matches the guide.

Two cases deserve a look before you click. A continuation line you aligned by hand under an opening bracket gets re-indented to the nearest whole level, which is the one place the button undoes deliberate alignment. And in a Python file that already mixes tabs and spaces, rewriting indentation changes which lines sit in which block. Clear the mixed indentation errors by hand first, then run it.

Getting a style rule to stick in a real team

Checking one file in a browser is the smallest version of this. Making it hold across a repository takes four steps, in this order.

1. Write down the choice. An .editorconfig file at the repository root gives every editor the indent character, indent width, and final newline rule. It is the cheapest step and the one most often skipped.
2. Put a formatter on save. Prettier, Black, or PHP CS Fixer removes the entire formatting category from human review. Nobody should be typing brace placement notes into a pull request.
3. Reformat once, in its own commit. Mixing a repository wide reformat with a behaviour change makes the diff unreviewable. Land formatting alone, then add the hash to .git-blame-ignore-revs so blame keeps pointing at the author who wrote the logic.
4. Fail the build, not the reviewer. Run the checker in the pipeline. A machine saying the indentation is wrong costs nothing. A colleague saying it costs goodwill twice a week.

Reading the three levels

Counts are counts, not a score. Twelve notes about quote style is a formatter run away from zero. One mixed indentation error in a Python file is a runtime failure waiting to happen. Sort by what a finding costs you, not by how many there are.

Where this page fits next to the others

Style findings answer whether a file matches a convention. They say nothing about whether the code underneath is any good. When the formatting is settled, the Code Complexity Analyzer shows which functions carry too many branches, and the Code Smell Detector looks for the structural patterns that survive any amount of tidy indentation.

For a syntax error rather than a style break, the JavaScript Syntax Checker parses the file properly and reports the failure position. Security concerns run on a separate ruleset in the Code Security Scanner, and turning any of this into a repeatable team habit starts with the Code Review Checklist Generator.

Guide settings were checked against the published Airbnb, StandardJS, Prettier, PEP 8, Black, PSR-12, Google Java Style, and Microsoft C# documents in August 2026. All checking runs in your browser. No code is uploaded, stored, or logged by Toolexe.