Roadmap

Many static analysis rule that ship with Pharo are still in the old SmallLint format which has limitations of how detailed an critique can be, how complex auto fix it can provide and even how fast it runs. Migration of the existing rules into a new format is always relevant and can be a nice introductory task to get used with the framework.

At the moment Renraku ignores exceptions signaled by static analysis algorithms to protect users against spontaneous crashes. On the other hand algorithm developers need to disable this guard to detect and debug errors in their code. To improve awareness of casual programmers and remove burden from algorithm developers we need smart error handling in Renraku where the presence of runtime exceptions will be reported together with other external properties of code.

At the moment developers can ban the rules from checking their code on a method, class and package levels. But some rules that explain Pharo idioms may be annoying for experienced developers who have to break the idioms for a specific reasons. This is why we need a way to disable rules for a whole image. On the other hand there are some rules as "Uncommented Class" that have to check Pharo Kernel classes despite decisions of casual developers, as uncommented classes will not be accepted into Pharo anyway. Thus we also need a way to enforce rules for certain Packages.

Smalltalk Pattern code can be used to match and rewrite smalltalk code is a very declarative way. On the other hand syntax is not easy to memorize and understand, while matching process itself is hard to debug. Over the last few years a couple of tools were developed to aid developers with the Pattern code. MatchTool performs the matching and allows one to inspect the results and build the match query incrementally. RewriteTool focuses on the code transformations and can be used to create static analysis rules. While the tools do a good job, we need a single tool to browse, create, analyze, edit, and remove static analysis rules based on the Pattern code.

The CI server of Pharo still uses the old model of SmallLint rules, which have their own limitations. We have to migrate the CI validation rule to the Renraku model and benefit from single critique format in all out tools. Imagine that the CI server will serialize a critique object and send it to you by email. Just throw the file into your image and address the critique.

With Renraku we can provide critiques about any object, but the current rules mostly focus on CompiledMethod and Behavior. A problem arrises when one wants to validate a code which is not installed in the image. Pharo uses (or should use) the Ring model which is a common code model used by all the tools. The goal of this milestone is to build rules that work on Ring objects polymorphic with the existing classes and methods, and see how we can use them for validating a code which is not installed in the code.

Most of the tools based on Renraku provide either live feedback as-you-program or an on-demand analysis. We need a quality feedback that works during a commit process: when a developer is about to commit new changes the tool would tell him whether new critiques appeared. Then we can shift the rules such as "Uncategorized Method" or "Uncommented Class" from live feed to pre-commit feedback.

As any piece of software, static analysis rules also need automated tests. Writing them is a slightly complicated process, as one has also to create code snippets with good and bad code and then test whether the rule detects issues in the bad code fragments and does not detect them in the good ones. Documentation is another common software development practice which quality rules should follow. And if we already have these good and bad code examples, why not include them in the documentation to better explain the intention for the quality rule. The goal of this project is to develop a framework where a developer is only supposed to provide code snippers for the rule, and the framework will use them for testing and documentation generation.