Hello, I’m a newbie using Graphviz mostly because of FreeCAD’s dependency graph, I’d like to know if there is a good linter for the DOT language (to polish the code generated by FC). I’ve only found redot-lint, but it looks unfinished, unmaintained and tied to the redot editor; do you know of any alternative?
Thanks in advance
I’m not aware of anything existing, but this is an interesting topic to me. The fact that Graphviz silently accepts unknown attributes is a bit of a footgun (e.g. you typo packk=true and wonder why your pack setting didn’t take effect). What specific problems are you looking to catch?
1 Like
As of now, the first problem is readability, the generated code has no indentation etc., while generally it works, even if in complex drawings it can be somewhat clunky
Oh so you really want a reformatter, not a linter? For this I usually use clang-format. Though it’s meant for C/C++, it does a surprisingly good job on Graphviz files.
I don’t know, isn’t a linter also about “cosmetic” issues?
Didn’t expect this, I’ll try. Is there any other reformatter specifically for DOT?
I suppose so, but a linter that tells you about e.g. overly long lines doesn’t seem particularly valuable. E.g. I don’t pay any attention to these kind of warnings in Python with Pylint. I just run Black.
Not that I’m aware of though it’s certainly been discussed before either on the forum or in a Gitlab issue. Search is failing me…
1 Like
dot -Tcanon myfile.gv (DOT | Graphviz) is a reformatter/prettyprinter, though there are no tuning capabilities - the format is what it is.
I have a gvpr program (insert eyeroll here) (inside joke) that identifies “useless” attributes (like rankdir applied to a subgraph), but that is all. It does not check the actual attribute values, nor does it flag engine-specific attributes (like len), let alone check for “reasonableness”.
1 Like
Thank you
This might be interesting, although I don’t know the internals of graph generation in FreeCAD
This is actually the kind of thing I thought @d1nuc0m was asking about initially. E.g. it was only through the recent nslimit discussion that I realized nslimit ≤ 0 possibly makes no sense. A linter could diagnose things like this.
1 Like
Not terribly difficult, a set of large tables to do the heavy lifting. Maybe trickier as you make it smarter.
While it can be done in gvpr, a different language would probably be better because gvpr has 1-dimensional arrays and a poor command-line argument capability (neither killers, but …)
Also it would be nice to make it an optional 1st pass for all the engines
1 Like
Yeah, in the early 1990s, outside my tiny office in our old space in Murray Hill Building 3 that we shared with the patent lawyers (the building had slightly positive air pressure to protect residents in case of a toxic chemical release elsewhere in the complex, installed for a previous generation of executives) I asked Dave Korn if we should enforce declaration before use, and he was definite against this (based of course on his own work). And here we are today! Someone could invent a tool (automatically generated) to check for attributes not defined in the graphviz documentation, possibly with an option to restrict the search for a specific graphviz tool or set of tools.
2 Likes
Why is this necessary? AFAIK everything necessary is already in the website sources. And thanks to @mark it’s even machine readabale. Probably not too hard to whip up something in Python that uses this as a source (famous last words…)
1 Like
Not sure which “this” you’re referring to.
I agree that the website source is a great start (that is what I used).
A linter is not tops on my list. Most of the misuse I notice is not consequential (see rankdir reference, above). But a linter might help the user understand that they are thrashing.
1 Like
Keeping in mind that accepting any attribute name is a feature, not a bug. The language philosophy, promulgated by @scnorth et al. 
, was to be forgiving in parsing and strict in output. In particular, users have to be able to add their own attributes. Any linter can flag undocumented attributes to catch typos, but it would be good if it allowed users to provide a whitelist of additional attribute names.
Exactly, yes.
Indeed. I use made-up attributes frequently.
Here are some “curated” results from some of my collected graphs. The XXconstraint, ROW, and COL are my doing, the rest were probably written by others.
All-in-all these bugs are not that common, and often just show a mis-understanding of the language (I was surprised that color was not a Root-graph attribute)
Warning: "rankdir" is is not a defined cluster attribute (cluster_0)
Warning: "rankdir" is is not a defined cluster attribute (cluster_2)
Warning: "rankdir" is is not a defined cluster attribute (cluster_3)
Warning: "bye" is is not a defined Edge attribute
Warning: "fontSize" is is not a defined Node attribute
Warning: "rank" is is not a defined cluster attribute (cluster_1)
Warning: "color" is is not a defined (Root) graph attribute (cfg")
Warning: "splines" is is not a defined Edge attribute
Warning: "color" is is not a defined (Root) graph attribute (cfg")
Warning: "splines" is is not a defined Edge attribute
Warning: "XXconstraint" is is not a defined Edge attribute
Warning: "COL" is is not a defined subgraph attribute (%237)
Warning: "ROW" is is not a defined subgraph attribute (%239)
Warning: "fillcolor" is is not a defined subgraph attribute (notcluster_tree1)
Warning: "label" is is not a defined subgraph attribute (notcluster_tree1)
Warning: "style" is is not a defined subgraph attribute (notcluster_tree1)