# CodeParser and CodeInspector

Posted 1 year ago
3683 Views
|
6 Replies
|
59 Total Likes
|
6 Replies
Sort By:
Posted 1 year ago
 I just wanted to say that I have been using this tool for a while, and I find it to be excellent. It is a big step forward for Wolfram Language development. It helped me find multiple bugs in my IGraph/M package (as well as some other private packages I use), and it is now a regular part of the testing routine I use for IGraph/M.Highly recommended for anyone who writes Wolfram Language packages!
Posted 1 year ago
 Thanks for sharing! Is there an explicit list of what types of errors get found?
Posted 1 year ago
 No explicit list right now. It is a goal to make the errors available programmatically, for better filtering and also easier translation to other languages, etc.
Posted 1 year ago
 I was wondering about adding new rules to the linter. There is a tutorial in the documentation, but it is a bit outdated.What is the difference between ConcreteRules, AbstractRules and AggregateRules, and which one should we look at first to get started?
 The philosophy is that it is easy to convert from Concrete -> Aggregate syntax, and also from Aggregate -> Abstract. So at those 3 stages, we do scans for rules that are defined.For people playing at home: Concrete Syntax: parse tree with whitespace are comments preserved (think InputForm) Aggregate Syntax: all whitespace and comments have been stripped. Abstract Syntax: nodes are transformed into more abstract forms (think FullForm)Most rules will be for Abstract syntax.You can ask yourself: Does the difference between 1+2 and Plus[1,2] matter for my rule? If no, then use Abstract Syntax. If yes, then ask: would whitespace affect the rule? If no, then use Aggregate Syntax. Otherwise use Concrete Syntax.It should be noted: I am also thinking of the best way to represent a level lower than Concrete Syntax, working directly with tokens. This would be where a rule for ;; at the end of a line would be. It would be wrong to have the rule ";; at the end of a line" as Concrete Syntax, because it is hard to check "end of line" in a tree structure. But with a list of tokens, just need to check ;; token is next to \n token. Maybe it will be called TokenRules or something.