Rules reference
Generated from jevgate rules --format json (jevgate 0.35.0). A rule is named by its ID,
its key or its group anywhere a rule is accepted: --rule, --skip-rule,
--fail-on TARGET=LEVEL, [rules], [[scope]] and jevgate: allow(…) comments.
Fails by default names the levels that fail the check under the default gate level,
mature: those right at least 80% of the time over at least 20 findings labeled from the code on
projects JevGate was never tuned on; an opt-in rule’s levels fail it once the rule is selected.
The other findings are reported without failing it, as is every finding in a
preview language, whose counts are its own.
Every finding is reported as a review; Reviews right and considers right give, for
the level its measured questions composed, how many labeled findings were right on
those projects, of how many labeled; a debatable one counts as not right. A note is
not reported, and a look-here question’s findings are not yet measured (-).
tests/laws is labeled only on Bend 2 projects, which these numbers leave out.
| Rule | Key | Default | Fails by default | Reviews right | Considers right | Question |
|---|---|---|---|---|---|---|
maintainability/file-organization | file_organization | yes | no | - | - | Does the file do several separate kinds of work, or test several unrelated modules, that a maintainer could keep in separate files? |
maintainability/function-simplification | function_simplification | yes | review | 87% (20 of 23) | - | Could the function be made noticeably simpler to read or change: is it long, deeply nested or repetitive, or does it mix separate jobs? Would splitting it into named functions, or flattening control flow nested four deep, make it easier to understand? |
maintainability/shared-logic | shared_logic | yes | no | - | - | Do repeated snippets express the same rule, lookup or sequence of steps, so that a maintainer should keep it in one place? |
maintainability/hardcoded-values | hardcoded_values | opt-in | no | - | - | Does a function or constant fix a value a maintainer should look at: one that singles out a record, place or user, differs between environments, is likely to change, or is an unexplained number? |
security/injection | injection | opt-in | no | 3 of 4 | 5 of 13 | Does a variable that another party controls reach the text of a query, command, code, markup, file path, requested URL or redirect target, or a deserializer, without being bound, escaped or checked? |
security/sensitive-data | sensitive_data | opt-in | no | 42% (10 of 24) | 0 of 5 | Does the function log a password, token, key or personal data, or send internal error details to a remote client? Does an error handler send clients more than the program’s own messages and codes? |
security/unsafe-settings | unsafe_settings | opt-in | no | 2 of 4 | 0 of 4 | Does the code turn off a security check or choose a weak setting: certificate verification, password hashing, random tokens, CORS, cookies, or secrets in environment variables the build puts into browser code? |
security/access-control | access_control | opt-in | no | - | - | Does a policy let every user it applies to reach other users’ rows, or trust a value users can change? Does a SECURITY DEFINER function leave search_path open or skip checking the caller? Does a grant open writes or private reads to every user? Does a public table hold users’ own data, a view return other users’ rows, or a reducer change rows its arguments choose, or admin-only settings, without checking the caller? |
security/workflows | workflows | opt-in | no | 1 of 1 | - | Can a run script execute text that people outside the repository write? Does a job run pull request code while it has secrets or a write token? |
tests/value | test_value | yes | no | 3 of 5 | 1 of 2 | Does the test check only its mocks, recompute the expected value with the code’s own logic, assert internal details, or mix unrelated behaviors? |
tests/redundancy | test_redundancy | yes | no | 1 of 1 | 60% (27 of 45) | Do the two tests check the same behavior, with different or equivalent inputs? |
tests/laws | laws | yes | no | - | - | Does the comment above a law promise more than, or something other than, what the law states, so a definition could break the promise while every proof passes? |
documentation/agent-context | agent_context | opt-in | consider | - | 92% (22 of 24) | Does a section restate what the repository’s files show, give generic advice, repeat what linters check, or record past work? |
documentation/large-docs | large_docs | opt-in | no | - | 1 of 1 | Would splitting the document make it easier to find and maintain, or does it mainly record past work? |
documentation/staleness | doc_staleness | opt-in | no | - | 2 of 2 | Is the document a plan whose work is finished, or does a section tell the reader to use a path or script that no longer exists? |
documentation/duplication | doc_duplication | opt-in | no | - | 15% (3 of 20) | Does one section state everything the other states, or do the two give different values or instructions for the same thing? |
documentation/comments | comments | opt-in | no | - | 54% (39 of 72) | Does a comment only repeat its code, hold sentences that add nothing, narrate an edit instead of the code as it is, or hold code turned off? |
Each rule’s page gives what it looks at, the evidence it sends, and findings it got wrong on open-source projects; accuracy explains how the labels are made.
Groups
- Maintainability: On by default, except hardcoded values: add it with
--rule default --rule hardcoded-values, or a level for it in[rules]. - Security: Opt-in:
--rule security, or a level in[rules]. - Tests: On by default. Test value and test redundancy are judged with
--include-testsorinclude_tests = true; the laws of Bend 2 code are judged without it. - Documentation: Opt-in:
--rule documentation, or a level in[rules].
Decision policy
Answers become findings in code at these thresholds; one named after a rule and question was measured for that question from labeled findings and replaces the shared one there:
| Setting | Value |
|---|---|
clear_probability | 0.8 |
consider_leading_probability | 0.5 |
consider_probability | 0.8 |
deep_nesting | 4 |
location_probability | 0.65 |
long_branch_chain | 4 |
look_probability | 0.7 |
min_bend_file_lines | 300 |
min_body_lines | 5 |
min_clone_bytes | 120 |
min_clone_statements | 3 |
min_file_lines | 100 |
min_repeat_tokens | 12 |
review_probability | 0.8 |