Design and Use of a Linter
As we discussed earlier, for style guidelines there is no clear division between error and warning. An error for a false loop in a cycle-based environment may be just a warning in an event-driven environment. Furthermore, there are various degrees of severity for errors and warnings. As a project progresses, a warning can be promoted to an error, and vice versa. Therefore, when implementing a linter, one should set the tool to have a user programmable error/warning system. For instance, it could issue seven levels of error and seven levels of warning, each corresponding to the categories in this chapter. It could have a command-line option to demote a class of error or to promote a class of warning.
Giving out warnings and errors is only the first step. The second step is to assist engineers to locate the code causing the warnings and errors. For some warnings and errors (such as combinational loops), the problematic code can be interspersed in several files. A graphical interface is helpful to show the connections among the code fragments. Keep in mind that a text-based interface is still required for the tool to be integrated into a verification flow.
In addition, a single root cause can generate multiple messages. For example, a false loop involving a bus can generate multiple loop messages, with each loop involving a particular bit. Conversely, an error can mask other errors; so, removing an error can unmask others and generate more. Both situations can be discouraging and misleading; therefore, a tool needs to limit the effects of these two extremes.
In summary, a good linting package has three components: a checker/linter that detects violations, a locator that assists users to locate the code causing the warnings and errors, and a report generator that creates reports and statistics.