What is a linter? A plain guide, and why we named Lintsure after it

A linter is a program that reads your source code without running it and points out lines that are likely to cause trouble: bugs, risky patterns, or code that breaks your team’s rules. You get a list of findings, each with a file, a line and a reason, before the code ships.

We named our product Lintsure because it is a linter. This guide explains what linting is, where the odd word comes from, and why we think the idea fits compliance surprisingly well.

Where the word “lint” comes from

Lint is the fluff that collects on clothes: small, loose fibres you only notice when you look closely. In 1978 Stephen C. Johnson at Bell Labs wrote a tool for C programs and called it lint, because it picked small, easy-to-miss problems out of code the way you pick fluff off a jumper. The compiler would accept the code; lint pointed at the parts that were probably wrong anyway, like a variable used before it was set or a function called with the wrong number of arguments.

The name stuck. Today “linting” means running any tool that checks code against a set of rules, in almost every language.

What a linter finds

Here is a short JavaScript file and what a typical linter says about it:

function total(items) {
  let sum = 0
  let tax
  for (var i = 0; i < items.length; i++) {
    sum += items[i].price
  }
  if (sum == "0") return null
  return sum
}

3:7   'tax' is assigned but never used           no-unused-vars
4:8   Unexpected var, use let or const instead    no-var
7:11  Expected '===' and instead saw '=='         eqeqeq

None of these stop the code from running. Each is a small thing that tends to turn into a bug later. That is the whole idea of lint: cheap, early, specific warnings.

How linting works

Most linters follow the same steps:

1. Read the files you point them at, skipping folders like node_modules.
2. Understand the code, either by parsing it into a syntax tree or by matching patterns line by line. Syntax trees are more precise; patterns are faster and work across many languages.
3. Apply rules. Each rule looks for one kind of problem. Rules are usually configurable: you turn them on or off, and some take options.
4. Report findings with the file, line, rule name and a message, often with a suggested fix. Many linters can fix simple issues automatically.

Because the rules are fixed code, a linter gives the same answer every time for the same input. That predictability is why teams trust it in CI.

Common linters by language

• JavaScript and TypeScript: ESLint, Biome
• Python: Ruff, Pylint, Flake8
• Go: golangci-lint, go vet
• Rust: Clippy
• Ruby: RuboCop
• CSS: Stylelint
• Shell scripts: ShellCheck
• Dockerfiles: Hadolint

Linter, formatter, type checker, security scanner

These tools overlap, and teams often use several together.

Tool	What it checks	Example
Formatter	Only how code looks: spacing, line breaks, quotes. Never changes behaviour.	Prettier, Black
Type checker	Whether types line up: you didn’t pass a string where a number is expected	TypeScript, mypy
Linter	Code that is valid but likely wrong, risky or against team rules	ESLint, Ruff
Security scanner (SAST)	Vulnerabilities, often by following data across files and functions	Semgrep, CodeQL

A rough way to remember it: the formatter makes code tidy, the type checker makes it consistent, the linter makes it careful, and the security scanner looks for ways in.

Setting up linting in a project

1. Pick the common linter for your language and install it as a development dependency.
2. Start from its recommended rule set rather than writing your own.
3. Commit the config file, so everyone uses the same rules.
4. Turn on the editor extension, so issues show as you type.
5. Run it in CI on every pull request, and fail the build on errors.

If an existing codebase produces hundreds of warnings on day one, fail only on new problems at first and clean up the rest over time. Otherwise people learn to ignore the linter.

False positives and suppressions

Every linter sometimes flags code that is fine. When that happens:

• Turn the rule off for that one line, with a comment saying why.
• If a rule is wrong for your whole project, change the config rather than sprinkling exceptions.
• Report clear false positives to the linter’s maintainers. That is how rules get better.

A suppression with no reason is a small problem waiting to happen: the next person can’t tell whether it was a deliberate decision or a shortcut.

Linting and AI-written code

Coding assistants write a lot of code quickly, and they write it confidently. A linter is a useful partner for them because it is the opposite: slow to change its mind and the same every time. Many teams now ask the AI to write the code and the linter to check it, then let the AI fix what the linter found. The AI is good at suggesting fixes; the linter is good at noticing.

Why we named Lintsure after it

Lintsure is a linter whose rules come from laws and standards instead of style guides. It reads your code and flags things like personal data written to logs, a live API key in the repository, or an AI feature that decides about people with no human check. Each finding has a file, a line, the controls it relates to in GDPR, SOC 2, ISO 27001 or the EU AI Act, and a suggested fix.

We kept the word “lint” because the tool works exactly like one:

• Small things, found early. Most compliance problems in code are small, one line here and there, and cheap to fix while the code is fresh.
• Fixed rules, same result. Lintsure is a rule engine, not a language model, so a report can be shown to someone else and reproduced.
• Lives where linters live. In the terminal, in CI on every pull request, and inside coding agents like Claude Code and Cursor.

The “sure” is about being ready, not about guarantees. A linter can tell you a line looks wrong; it can’t tell you your whole company meets a law. That needs policies, records and people. So Lintsure also lists the work that lives outside code, and every report says plainly that it is a readiness check, not an audit.

Lint was always about the small fibres you only notice up close. That’s the part of compliance a tool can actually help with.

Read more in compliance linting: checking code against GDPR, SOC 2 and the EU AI Act, or see all the rules.