Inspector Eiffel: code analysis in EiffelStudio
Inspector Eiffel, a tool for rule-based static program analysis, has been added to EiffelStudio. Inspector Eiffel comprises a framework and a tool for light-weight static code analysis. It helps maintain high code quality. As of now it is capable of detecting more than 35 issues in the source code. More rules are already being developed. The issues Inspector Eiffel detects relate to possibly dangerous runtime behavior, performance problems, coding style, and more.
The tool appears as a panel with a list of rule violations, which is populated upon analyzing the (compiled) source code. This output may be sorted and filtered by various criteria such as category, severity, affected class, and more. The panel enables the programmer to navigate to the problematic source code locations. Additionally, Inspector Eiffel enables automatic fixing of certain rule violations.
Inspector Eiffel can be customized by setting miscellaneous preferences. For example, rules (as well as whole rule categories) may be disabled and enabled (also for single classes).
The online documentation  contains additional information for the user and for the developer.
Inspector Eiffel originates from my Master thesis project .
 Inspector Eiffel online documentation. https://dev.eiffel.com/User:Stefan/Code_Analysis  Stefan Zurfluh, Rule-Based Code Analysis, Master thesis, ETH Zürich, Chair of Software Engineering, 2014. http://e-collection.library.ethz.ch/eserv/eth:8509/eth-8509-01.pdf
Will this be in the 14.05 release?
I guess so, because it has already been added to the main code repository. We should forward this question to the people from EiffelSoftware.
Like it -- Love it -- Want more of it!
It is my understanding from Manu and the documentation I have seen that there are about 90 or so rules and about half of them have been coded. With the rules coded and delivered so far in beta of 14.05, we have performed a very intense review, coming away with only a few minor apparent bugs or items needing attention. My overall assessment is that this tool will become a many-times-per-day staple in our Eiffel regimen. What I am deeply excited about is the capacity to write our own rules and to start moving human code review to Inspector-based code review as much as humanly possible. From my point of view, this is an "Expert System" for our Eiffel code. My hope is that the tool is capable of looking beyond class feature AST and into Client-Suppler, where we can specify rules for monitoring how client classes interact with their suppliers.
Very large Kudos to the folks at ETH and Eiffel Software for making this one happen. Again -- as Eiffelists -- we have tools that no other language system has for improving the quality, stability, reliability, and robustness of our systems.
Have a great day and happy Eiffeling, Ya'll!
What are the Origins
I have been recently introduced to the reality that there are lots of static code analysis tools for many other languages. A large collection of links to static code analysis tools can be found in the WikiPedia.
What I would like to know is: What is the genesis or inspiration for Inspector Eiffel? Is this tool something new or does it share qualities with other static analysis tools? What are the differences? What are the similarities? Is there anything about IE that distinguishes it from it possible counterparts other than it is written in Eiffel for Eiffel?
Eiffel Inspector and other tools
Eiffel Inspector (as it is called now) arose out of the lack of such a code analysis tool for Eiffel. I am not aware of any existing tool being capable of analyzing Eiffel source code.
The rules Eiffel Inspector operates with were carefully chosen for Eiffel and were designed with the Eiffel principles in mind. For instance, the "command-query" separation rule, the "from-until into across" rule, and the "object test local" rule are among the rules that are specific to Eiffel. Other rules analyze properties that also apply to many other programming languages. In fact, many tools include implementations of such common analyses (unused variables, missing comments, etc.), which function at least in a similar way to what Inspector Eiffel does.
Another remark regarding the reasons for developing Eiffel Inspector: Since Eiffel Inspector started out as a research project, the tool was developed with the prospective combination and integration of different static and dynamic verification and testing tools in mind . One possible way would be to have a one-button analysis that involves verification using proofs, static analysis, and automatic testing. (This fact applies to the research branch of EiffelStudio only. It is not related to the current EiffelStudio release.)
 Software Engineering Research at ETH