marimo lint for best practices.

[dmadisetti]

This is a running list of lint ideas in no particular order, an id is only provided to facilitate discussion. Feel free to chime if you have ideas (thanks @bossjones for sharing your rules):

id	rule	description	motivation
1	Maximize import only cells	Avoid importing commonly used libraries in cells with notebook logic	import-only cells are handled in such a way that new imports do not rerun the entire notebook
2	Maximize toplevel definition cells	In cells with a single function/ class definition, attempt to resolve issues to become a top level function (e.g. @app.function, @app.class_definition)	This format reduces boiler plate, and makes cells reusable / easily exported to other notebooks or modules
3	Serialization of file matches file content	Ensure that loading the marimo notebook and saving it produces the same output	Using the editor on the notebook may produce unintended changes
4	No object mutation between cells	Calls to __setattr__, __setitem__, and __i*__ on an object should be avoided	Mutations can lead to unintended accumulation of state. Moreover, this code will act differently in strict mode
5	-	Existing warnings (like UIElement as truthy #5299)
6	-	Calling a cached function from another cached object
7	-	Having potential ContextExecution cache hits

Relevant issue: #1543

Some goals:

If there is synergy between a python best-practice, and a marimo best-practice, then prefer changing marimo to better align with the python practice.
Some previous examples of this are

• renaming default cells __ to _, such that linters recognized the cell function do not require a name;
• pruning return values if variables are not used in other cells to catch dangling definitions;
• Removing cell definitions from references in producing the cell signature (prompting reportPossiblyUnboundVariable in pyright)

Linter hints should not be stylistically paternalistic, but have a clear performance or clarity improvement specific to marimo
Under this criteria

• Non-ideal suggestion: Providing a hint that a cell is too large, or has too many definitions. Reasoning: The messiness of this is subjective, not specified under any python standard, and has no marimo specific advantages or penalties
• Reasonable suggestion: Providing a hint that breaking up a cell can produce a flatter DAG. Reasoning: This can improve runtime performance.

[bossjones]

for sure ! happy to help and dogfood anything as well ! @dmadisetti

[dmadisetti]

Have you tried the library mode in experimental flags?