33
$\begingroup$

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.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ I wonder if you could make something like this get your features? mathematicaplugin.halirutan.de $\endgroup$
    – Moo
    Commented Apr 16, 2016 at 12:11
  • 1
    $\begingroup$ How is this different from the little popups that appear over each command when you hover the mouse? Or the "context sensitive" help? $\endgroup$
    – bill s
    Commented Apr 16, 2016 at 14:14
  • 1
    $\begingroup$ Like bill s I would say that a very strong capability along the lines you describe already exists in Mathematica. $\endgroup$
    – m_goldberg
    Commented Apr 16, 2016 at 15:42
  • 8
    $\begingroup$ 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? $\endgroup$
    – WReach
    Commented Apr 16, 2016 at 16:03
  • 1
    $\begingroup$ @WReach Ideally this is what Workbench would do if version 3 ever comes out of beta. $\endgroup$
    – Edmund
    Commented Apr 16, 2016 at 22:34

1 Answer 1

Reset to default
46
$\begingroup$

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.

summary of code linting

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!

Improve this answer
$\endgroup$
13
  • 4
    $\begingroup$ 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 $\endgroup$
    – Mark S.
    Commented Mar 6, 2019 at 1:38
  • 4
    $\begingroup$ And, of course, the first thing I should have said is that having these tools is really great! Thanks for all your work. :-) $\endgroup$
    – Szabolcs
    Commented Mar 6, 2019 at 19:24
  • 6
    $\begingroup$ Big +1, Have you considered putting it e.g. on GitHub? @Szabolcs would have more space for issues :) $\endgroup$
    – Kuba
    Commented Mar 6, 2019 at 22:35
  • 3
    $\begingroup$ @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. $\endgroup$
    – brenton
    Commented Mar 8, 2019 at 18:10
  • 6
    $\begingroup$ The CodeInspector has now been made available on GitHub: github.com/WolframResearch/codeinspector $\endgroup$
    – brenton
    Commented Apr 8, 2020 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.