Semantic linter

Historically, linters have needed lots of software to parse and analyse your code. With Neo, it is possible to create new linting rules with just a sentence. We call this “semantic linting”.

For example, in Python you could write a rule “N013 dataclass is forbidden, only use pydantic BaseModel”. See Sagittal’s internal Python semantic linting rules for more examples.

This is useful for:

  • Adding linting rules your language’s linters don’t yet support

  • Adding rules that are specific to your team and codebase

We’ve found giving the rules a number, and making them specific and deterministic, is most successful.

Setting up rules

You can set these in two ways:

  1. Edit the .neo/semantic_linter_rules.md file on the default branch in a code repository. This will set the rules for just that repository.

  2. Create a document in your document manager (e.g. Confluence), with rules for either the whole project or for multiple repositories. Then give that URL to your Neo administrator, and ask them to set it as semantic linter rules in Context documents.

In either case, make a table or list containing the first rule or two that you can think of.

It is best not to worry too much about what the rules are to start with. Instead, get set up and incrementally add more rules as you come across them in the course of work.

⚠️ Neo will also use semantic linter rules while writing code.

Often teams have a separate document with company code style guidelines in which isn’t suitable for semantic linting. Set that in Context documents as well.