Papyrus Linter

Papyrus Lint goes far beyond style: it catches bugs that CreationKit's compiler lets through.

PapyrusCompiler.exe only checks that a script is syntactically valid — it will happily compile a script that dereferences a None object at runtime, passes a String where an Int is expected, returns the wrong type from a function, compares an Int to a Float inexactly, or contains a branch or statement that can never execute. Those bugs don't show up until later, as a CTD, a quest stage that never advances, or a value that's silently wrong — often far from the line that actually caused them, and long after the mod author has lost the context to spot it. Papyrus Lint performs deep correctness, reliability, and performance checks across your .psc source (see the full list below), on top of the formatting and style checks a linter usually provides, so a mod author finds these problems at write time instead of from a bug report.

Links

• []Discord[/]

  []GitHub[/]

  []Website[/]

  []VS Code Extension[/]

  []Feedback on Tally[/]

Simple Example

Function DoSomething(Actor a, Actor b, Form SomeItem)

a. RemoveItem(SomeItem, 1, b);

EndFunctionThis compiles, but the likely desired version is:

Function DoSomething(Actor a, Actor b, Form SomeItem)

a. RemoveItem(SomeItem, 1, false, b);

EndFunction This would be found by the Strict Boolean Rule. More examples here.

If you actually meant it, feel free to disable the lint:

Function DoSomething(Actor a, Actor b, Form SomeItem)

a. RemoveItem(SomeItem, 1, false, b); @disable

EndFunction

What this is NOT

• []A compiler[/]

  []An editor[/]

  []A guarantee a script is fit for purpose[/]

  []A replacement for proper testing[/]

  []AI-based, this is a rule based system instead[/]

  []Network enabled[/]

  What is a linter?

  A linter is a tool that scans source code for patterns that are likely to be mistakes, bad practice, or inconsistent style, without actually running the code. It works from heuristics — recognizable patterns known to often cause problems — rather than proving that a given line is definitely wrong. Because of that, a linter can produce false positives: diagnostics on code that is actually fine, especially for patterns the checks intentionally can't fully resolve (see e.g. "Strict boolean check" or "None used as an existing Form" below, which skip anything they can't determine with confidence rather than guess). It's normal to disagree with an individual diagnostic and dismiss it.

  Treat every diagnostic here as advice, not a guaranteed defect report: a suggestion worth a second look, not proof the code is broken. Use your own judgment for whether a flagged line needs changing, and use the disable comment below to silence a specific rule on a specific line when you've decided it doesn't apply.

  How is this tested?

  Testing uses three steps to make sure everything is working as intended. Step one is automatic test coverage, currently covering 26,026 of 26,796 lines(~97. 1%). Step two are testprojects I'm running manually and automatically in the GUI, that make sure the lints actually catch what they are intended to without too much noise. Lastly I'm running the tool on actual projects of mine and check every lint result - this is part of my workflow by now and has provided value to me.

  Implemented Lints in v1. 40. 0

  More detailed explanation of the rules and their implementation is available on the GitHub README: https://github.com/Idrinth/papyrus-lint

  Formatting

  These lints make scripts easier to read by enforcing a consistent look and feel. They are especially useful in group projects.

  Description

  Spacing around assignment operators

  Requires exactly one space on either side of =, +=, -=, *=, /=, and %=.

  Whitespace interrupting property/method chaining

  Flags a space or tab immediately before or after a member/method access.

  Space after comma

  Requires whitespace after commas in argument lists.