As some of you might already know, the first topic I have chosen to work on is updating rules. For the most part, I am rewriting rules in a newer, more comprehensible format, sometimes changing the rule completely so it would be more efficient and useful. As can be seen in my repository, I have already updated a few rules, made an auto fix that creates methods that do not yet exist, and this weekend I have been working on creating a node version of the RBBadMessageRule and testing its performance.
Here is how check:forCritiquesDo: looks in the original RBBadMessageRule:
The way it was finding the interval was not that effective — the rule did not know what precisely the location of the bad code segment in the method was, as it only knew which of the badSelectors was being used, and searched for it in the code.
The original rule also analysed the whole method, whereas I decided to use another type of a rule that would only analyse a single node.
So this is how I rewrote this rule using aNode:
These days more tools are working with nodes. Besides, as you can see, the original version is much harder to understand as it has more lines and is generally written in a less clear way. Also now we have an ast node object representing the message, and in future it might be subject to further improvements.
To see whether the second version was also more effective than the first one, I started testing the performance, i.e. the speed each of these rules took to run. It turned out that the node version (RBBadMessageRule2) worked much faster than the original one (RBBadMessageRule).
Moreover, while checking a method, we are traversing the tree only once and we are not adding a big overhead for that.
For now, I am still in the process of testing just how accurately the second version works.
To be continued…