new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Deno · all subjects

cli: lint

17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

explicit-function-return-type lint rule requires return type annotation

The explicit-function-return-type lint rule requires all functions to have explicit return type annotations. This improves code clarity and type safety by making it clear from the function signature what type will be returned.

explicit-function-return-type invalid example

Functions without explicit return type annotations are invalid under this rule. Example invalid code: function someCalc() { return 2 * 2; } and function anotherCalc() { return; }

explicit-function-return-type valid example

Functions must have explicit return type annotations to be valid. Example valid code: function someCalc(): number { return 2 * 2; } and function anotherCalc(): void { return; }

getter-return lint rule requires return value

The getter-return lint rule requires all property getter functions to return a value. Getter functions return the value of a property, and if the function returns no value then this contract is broken. This rule is tagged as recommended.

getter-return invalid example - object getter

A getter function in an object literal that returns no value is invalid: let foo = { get bar() {} };

getter-return invalid example - class getter

A getter function in a class that returns no value is invalid: class Person { get name() {} }

getter-return valid example - object getter with return

A getter function in an object literal must return a value: let foo = { get bar() { return true; } };

getter-return valid example - class getter with return

A getter function in a class must return a value: class Person { get name() { return "alice"; } }

jsx-boolean-value rule enforces consistent JSX boolean syntax

The jsx-boolean-value lint rule enforces a consistent style for JSX boolean attributes. When passing true as a boolean value, the shorthand syntax should be used (omitting the value). Passing false as a boolean value should be explicit. Valid syntax includes <Foo isFoo /> for true and <Foo isFoo={false} /> for false. Invalid syntax includes <Foo isFoo={true} /> and <Foo isFoo={false} /> (when the shorthand should be used instead).

jsx-boolean-value is a recommended rule

The jsx-boolean-value lint rule is tagged as recommended, meaning it is part of Deno's recommended linting rules.

no-setter-return rule disallows returning values from setters

The no-setter-return linter rule disallows returning values from setter functions. Returned values from setters are ignored and cannot be used, making returns from setters a mistake that should be caught. However, returning without a value (early return) is allowed and is a useful technique.

no-setter-return invalid examples

The following patterns violate the no-setter-return rule: returning a string value from a setter in an object literal, returning a string value from a private setter in a class, and conditionally returning a number value from a setter.

no-setter-return valid early return pattern

Returning without a value from a setter is allowed and is a valid technique for early return from a function, for example when a condition is met.

no-sloppy-imports lint rule requires explicit file extensions

The no-sloppy-imports lint rule enforces specifying explicit references to paths in module specifiers. This means imports must include the file extension (like .ts or .js) rather than omitting it. Non-explicit specifiers are ambiguous and require probing for the correct file path on every run, which has a performance overhead.

no-sloppy-imports only active with --unstable-sloppy-imports flag

The no-sloppy-imports lint rule is only active when using the --unstable-sloppy-imports flag.

no-sloppy-imports example invalid imports

Invalid imports that violate the no-sloppy-imports rule: 'import { add } from "./math/add";' (missing .ts extension) and 'import { ConsoleLogger } from "./loggers";' (directory import without index.ts).

no-sloppy-imports example valid imports

Valid imports that comply with the no-sloppy-imports rule: 'import { add } from "./math/add.ts";' (explicit file extension) and 'import { ConsoleLogger } from "./loggers/index.ts";' (explicit index.ts path).

Give your agent this brain