This video introduces linters and formatters, two tools you can run as the agent changes your code. We'll see what each does, use a small diff to see how consistent formatting makes review easier, and run both tools in Python and TypeScript. Then we'll fix one real lint report, and turn a project convention into a lint rule.
Let's start by separating two tools that usually get mentioned in the same breath. A linter looks for patterns in your code that are perfectly legal, but suspect. An unused import, a comparison that is always true, a variable that quietly shadows another one. More generally, a linter reports the code problems and convention violations that its configured rules select. It reports what it finds, and by default it changes nothing.
A formatter does something much narrower. It standardizes the formatting of your code into one canonical form, without changing what the program does. It decides where the line breaks fall, how deep the indentation goes, whether there is a space after a comma, and which quotation marks a string uses.
Consistent formatting pays off when you review changes. Here is an example diff from a project without it. The requested change raises the tax rate, but the agent also changes the function's spacing. The diff shows three removed lines and three added lines.
Only the tax-rate edit, from zero point one seven to zero point one eight, changes behavior here. The rest is spacing. A diff dominated by layout invites skimming instead of reading, which makes that meaningful change easier to miss.
Compare that with the same edit in an already formatted file. The file is in canonical form before the edit and after formatting it again. In this example, the spacing edits disappear, leaving the old and new line with the changed tax rate.
Consistent formatting removes avoidable layout differences, making the meaningful edits easier to find. That helps when an agent produces a large diff and you need to understand what changed.
The tools each have a command you can run in the project. For Python, run "ruff check dot". For TypeScript, run "npx eslint dot" with the project's ESLint configuration in place. Each linter checks the files selected by its configuration and reports violations of the enabled rules.
Both linters have a fix flag: "ruff check dash dash fix dot", or "npx eslint dash dash fix dot". They apply available automatic fixes and report the remaining issues. Review the changes and resolve what is left.
To format the code, run "ruff format dot" in Python, or "npx prettier dash dash write dot" in TypeScript. Each rewrites the project's supported files into one canonical form, reducing formatting differences in the next review.
The linter exits non-zero for errors, making failure visible to a program as well as a person. Formatter write mode fixes the formatting. "Ruff format dash dash check dot" and "npx prettier dash dash check dot" instead fail when the formatting needs changing. Use write mode while editing. Use check mode when you want the command to report a failure without changing any files. Ask the agent to run the linter and formatter before reporting completion.
Here is what one lint report looks like. The file billing dot py imports the o-s module and never uses it. "Ruff check dot" reports "rule F four zero one" was violated, "o-s imported but unused". It gives the file, the line and the column, and suggests removing the import. The command exits non-zero, so the agent can tell that the check failed.
The asterisk in brackets marks a report that Ruff can fix automatically. "Ruff check dash dash fix dot" removes the unused import, and reports "found one error, one fixed, zero remaining".
Running the check again confirms the fix. It reports "All checks passed", and the command exits with zero. This is the loop you want the agent to follow. Read the report, fix the cause, and run the check again until it is clean.
A linter can also check conventions chosen for your project. Tests and types can express project requirements too. Lint rules are useful when the convention can be identified as a pattern in the code. Suppose your project keeps all database access in one package, called d-b. Only that package may import sqlite three. A sentence in the instruction file asks the agent to follow that convention.
Make the convention executable. A linter sees every import statement, so this rule is a pattern it can check. In Ruff, the extend-select line turns on the rule for banned imports, and the banned-api setting names the module to ban, here sqlite three. Ruff then reports every file that imports it, except the files in the d-b package, which the per-file-ignores setting exempts. In ESLint, the no-restricted-imports rule does the same. Linters can take other rules as well. Essentially, anything you can program as a check on the code can become a lint rule. The sentence asks the agent to comply. The lint rule reports every violation, each time it runs.
There are places where linters can do harm. Imagine a rule that forbids printing, turned on in a command line tool whose whole job is to print. All three of these lines get reported, and all three of them are correct.
Suppression comments make these reports disappear. Those lines are no longer checked for this rule.
If printing is appropriate for the whole command-line module, configure the scope instead, using Ruff's per-file-ignores or an ESLint configuration override. Here, two lines in "py project dot toml" switch off the printing rule for CLI dot py only. Every other file is still checked.
A rule that constantly reports acceptable code can leave you with suppression clutter and less trust in its warnings. Start with the standard configuration rather than enabling every rule. Use the reports during real work to decide which rules help and which need a narrower scope.
So let the formatter keep your diffs about behaviour. And let the linter carry your project's rules. It catches likely bugs and broken conventions in seconds, so the agent fixes them before you ever read the code. Start with your project's standard setup, and it will serve you well. Thanks for watching, and I'll see you in the next video.