prolint example rule using the new API
Tue, 2008-08-26 11:03 — jmls
Once the parseunit has been initialized and the cu parsed, the following is an example of a "missing NO-UNDO" rule:
DEF BUFFER ChildNode FOR TTNode.
FOR EACH TTnode WHERE nodetypenum EQ NodeTypes:DEFINE# AND NodeTypenum2 EQ NodeTypes:VARIABLE# NO-LOCK: /* DEFINE and VARIABLE */
IF CAN-FIND(FIRST ChildNode WHERE ChildNode.Parent EQ TTNode.Nodenum AND ChildNode.NodeTypeNum EQ NodeTypes:NOUNDO#) THEN NEXT. /* move to the next DEF VAR */
MESSAGE substitute("Define Variable At Line &1 Col &2 has missing NO-UNDO.",TTnode.NodeLine,TTNode.NodeCol) VIEW-AS ALERT-BOX INFORMATION.
/* obviously at this point we could do all sorts of things (publish to handler, create record etc etc) */
END.
Jurjen, have you any thoughts on the structure of the new prolint rules ? Are you going to use a class (ProlintRules.cls) that has methods for each rule, or a separate .p for each rule ? It would be a trivial task for the rule to return a list of nodes affected by the rule (possibly as a variable integer extent) or we could publish at each hit.
Looking forward to comments
- Login to post comments
Re: prolint example rule using the new API
That's pretty darn cool. :-)
As an aside...
See
wip/proparseclient/nodetypes.i. We'll want a class full of static properties, say "NodeTypes.cls", so that we can reference node types by names, rather than by numbers.For example:
...Except that we're going to have to use a prefix or suffix on the names, because many of the names like DEFINE are reserved keywords.
do you have any problem with
do you have any problem with adding a "#" to the end ? It works for all node types (compiles just fine)
... DEF STATIC PROPERTY ABSOLUTE# AS INT NO-UNDO INIT 20 GET . PRIVATE SET . DEF STATIC PROPERTY ACCELERATOR# AS INT NO-UNDO INIT 21 GET . PRIVATE SET . DEF STATIC PROPERTY ACCUMULATE# AS INT NO-UNDO INIT 22 GET . PRIVATE SET . DEF STATIC PROPERTY ACTIVEWINDOW# AS INT NO-UNDO INIT 23 GET . PRIVATE SET . DEF STATIC PROPERTY ADD# AS INT NO-UNDO INIT 24 GET . PRIVATE SET . ...so, the code would be
Adding # to the end reminds
Adding # to the end reminds me of 1985 Varnet code. Yuck.
If you would just start using my version of Hungarian notation, you wouldn't have this problem ... it is one of the virtues. I.e., inAbsolute, inAccumulate.
in for Integer ? MESSAGE
in for Integer ?
MESSAGE NodeTypes:inInteger
MESSAGE NodeTypes:INTEGER#
not sure which one is worse ;)
The 'Systems Hungarian
The 'Systems Hungarian Notation' is worse.
http://en.wikipedia.org/wiki/Hungarian_notation
With the quality of IDEs these days and their ability to show popup information, the Systems Hungarian Notation is nothing but pointless clutter, and a soother for people who got too attached to it.
Recognize that I am talking
Recognize that I am talking specifically about my version of Hungarian notation ... there are a bunch of different styles and some of them are indeed rather silly. In fact, I believe I quoted from that Wikipedia page exactly to show a silly example.
And, some of us don't find it pointless clutter at all. One of its functions is disambiguation, e.g., chValue being the string display equivalent of inValue. Another function is avoiding keyword conflict ... not just for current versions but for future versions. I'm sure we've all had the painful experience of creating variables and field names that seemed perfectly reasonable at the time, but which then became keywords in later versions.
And who wants to have to hover over every variable just to tell what type it is. I don't recall this being a feature of OEA anyway ... there you have to leap back to the define, which is even more painful.
I don't know any reason not
I don't know any reason not to use that. Seems OK to me.
glad you liked it. Now, I
glad you liked it. Now, I only need to convince Jurjen :)
Are you reading over my shoulder ? I am in the middle of a Nodetypes:Generate() to automatically create a class, just like schema.cls ...