# Is there a linter to help write good Mathematica code?

I don't do much real programming, but I've recently been turned on to Atom, which has linter plugins for over 50 languages to make coding easier (most drawing on pre-existing lint-like programs).

In other languages, linters help me learn about operator precedence (unnecessary parentheses), good programming styles/techniques, and get warnings about code that may not have been intended. Is there something along these lines for Mathematica?

If not, is there a reason why not? At first glance it seems like a number of the suggestions/tips I pick up from reading answers here could be automated. For example, maybe the Mathematica linter would remind you to memoize your functions with f[n_]:=f[n]= if that setting is turned on.

Edit: For a couple days in November 2016 there was work on a linter for Atom for Mathematica on github, but the project seems to have died quickly and I couldn't get it to work.

• I wonder if you could make something like this get your features? mathematicaplugin.halirutan.de
– Moo
Apr 16, 2016 at 12:11
• How is this different from the little popups that appear over each command when you hover the mouse? Or the "context sensitive" help? Apr 16, 2016 at 14:14
• Like bill s I would say that a very strong capability along the lines you describe already exists in Mathematica. Apr 16, 2016 at 15:42
• I don't know of one, but it would be cool to have warnings for private symbols that start with an uppercase letter, implicit multiplications at line boundaries, and unlocalized iterator variables in Table constructs within functions (just to name the first few ideas that popped into my head). The pitfalls post would be an excellent source of inspiration for checks to implement. I wonder if a bit of spelunking would turn up a way to extend the front-end's existing bare-bone checks? Apr 16, 2016 at 16:03
• @WReach Ideally this is what Workbench would do if version 3 ever comes out of beta. Apr 16, 2016 at 22:34

I am a developer at Wolfram Research and I have been working on linter technology that I think would be nice to share publicly.

There are 2 paclets on the public paclet server that you can download and use for finding problems with WL code.

The two paclets you will need are CodeParser and CodeInspector:

In[1]:= PacletInstall["CodeParser"]
Out[1]= PacletObject[CodeParser,1.0,<>]

In[2]:= PacletInstall["CodeInspector"]
Out[2]= Paclet[CodeInspector,1.0,<>]


The CodeParser paclet provides functions for parsing WL code and returning syntax trees with interesting metadata attached, such as file and line information.

The CodeInspector paclet uses CodeParser and provides functions for scanning WL code and finding problems and reporting them.

Here is a demo of using the CodeInspector paclet.

First, load the CodeInspector package:

Needs["CodeInspector"]


Next, take a snippet of code that you are interested in linting.

code = "Which[a, b, a, b]";


Use CodeInspect to get a List of InspectionObjects:

lints = CodeInspect[code];


The InspectionObjects are interesting by themselves, but it would be nice to see them formatted within lines of the source code.

CodeInspectSummarize[code]


The report shows formatted lines that you can mouse over to see the problem descriptions.

I included a screenshot to better show the result.

It is possible to also scan files with by doing CodeInspect[File[file]]

Both the parser and linter are open-sourced here:

https://github.com/WolframResearch/codeparser

https://github.com/WolframResearch/codeinspector

I hope you enjoy using them!

• When you solicit the community, you may want to look at things like the current "hot meta post" Linting - Code analysis for bugs, errors and style issues in the Wolfram Language Mar 6, 2019 at 1:38
• And, of course, the first thing I should have said is that having these tools is really great! Thanks for all your work. :-) Mar 6, 2019 at 19:24
• Big +1, Have you considered putting it e.g. on GitHub? @Szabolcs would have more space for issues :)
– Kuba
Mar 6, 2019 at 22:35
• @MarkS. Thank you for the link. @Szabolcs Thank you for the comments. The current limitation to ASCII characters is a consequence of using RunProcess. This will be fixed in the next update of AST which will use LibraryLink. In general, handing the contents of a file to LintString is not equivalent to LintFile. Compare this with ToExpression["a\nb"], which returns only b, and ParseString["a\nb"] which returns only the node for b. Though this could possibly be made to work in the future. @Kuba We are working on getting this on GitHub in the near future. Mar 8, 2019 at 18:10
• The CodeInspector has now been made available on GitHub: github.com/WolframResearch/codeinspector Apr 8, 2020 at 19:06