WO2005091139A2

WO2005091139A2 - Method for evaluating code checking reports

Info

Publication number: WO2005091139A2
Application number: PCT/EP2005/050341
Authority: WO
Inventors: Michael KÄLBLING; Briktius Marek
Original assignee: Siemens Aktiengesellschaft
Priority date: 2004-03-17
Filing date: 2005-01-27
Publication date: 2005-09-29
Also published as: WO2005091139A3

Abstract

The invention essentially relates to a method whereby reports of a code checker tool, such as PC-Lint, which generates, for example, messages of the categories 'Error', 'Warning', 'Information' and 'Note' for known problems of the examined source code, are compressed and converted into a fanlike diagram, in order to obtain, especially for extensive source codes, a very quick, qualitative overview of the state and/or modifications of the examined source code on different levels, for example on a project level.

Description

description

Procedure for evaluating code reviewer reports

The invention relates to a method for evaluating so-called code checker reports, such as those generated by tools for checking the source code.

When checking the source code of large software systems using commercially available tools such as PC-Lint (http: // www. Gimpel. Com), extensive reports are generated. In many cases, the amount of textual data generated in this way is so extensive that it can only be evaluated with great effort or not at all manually.

Known verification tools, such as Sotograph (http: // www, software-toitjography ■ de), also partially display the information obtained as part of the source code verification.

The object on which the invention is based is now to specify a method for evaluating code checker reports in which, in particular, source codes of large software systems can be checked particularly quickly and easily at different levels.

This task is solved according to the invention by the features of patent claim 1 or 10. The further claims relate to preferred embodiments of the invention.

The invention essentially consists in that reports of a code checker tool, such as, for example, PC-Lint, which, for. B. Messages of the categories "Error", "Warning", "Information" and "Note" to recognized problems of the source code under investigation are generated, compressed and converted into a fan-like diagram in order, especially with extensive source codes, to be very fast, qualitative Get an overview of the status and / or changes in the source code under investigation at various levels, e.g. at project level. The invention is explained in more detail below on the basis of exemplary embodiments illustrated in the drawings. It shows

1 shows a fan-like diagram to explain the invention and FIG. 2 shows a variant of the fan-like diagram to explain the invention.

The procedure is described here using the example of the PC-Lint tool, but can be easily adapted to other code checkers or code checkers as long as they provide their results in a similar, textual form. The starting point for the method according to the invention are, for example, so-called PC lint reports. An excerpt from a PC Lint report is shown as an example in Table 1 below.

_utils, cpp (C ++)

Line 0: Option: + rw (inline)

Line 0: Option: + rw (_to_semi)

Line 0: Option: + r (typeo)

Line 0: Option: -rw <asm, _asm, asm)

Line 0: Option: + rw (_ignore_init) d: \ sr \ projects \ GenericArriba \ snapshot_mk \ GenericPre_VO09 \ siemens \ siemenscpp \ src \ vp \ comnion \ gps _utils.cpp: l: 7: Note 970: Use of modifier or type 'char' outside of a typedef [MISRA Rule 13] d: \ usr \ projects \ GenericArriba \ snapshot_mk \ GenericPre_V009 \ siemens \ siemenscpp \ src \ vp \ common \ gps _utils.cpp: 108: 0: Note 1904: Old-style C comment - Effective C ++ # 4 d: \ usr \ projects \ GenericArriba \ snapshot_mk \ GenericPre_V009 \ siemens \ siemenscpp \ src \ vp \ common \ gps _utils.cpp: 110: l: Note 960: Violates MISRA Required Rule 87, only preprocessor Statements and comments before '#include' d: \ usr \ projects \ GenericArriba \ anapshot_mk \ GenericPre_V009 \ siemens \ siemenscpp \ src \ vp \ common \ gps _utils.cpp: 110: 9: Info 829: A + headerwarn Option Was previously issued for header 'stdio.h' [MISRA Rule 1243 d: \ iasr \ projects \ GenericArriba \ snapshot_mk \ GenericPre_V009 \ siemens \ siemenscpp \ src \ vp \ common \ gps _utils.cpp: lll: l: Note 960: Violates MISRA Required Rule 87, only preprocessor statements a nd comments before '#include' d: \ usr \ projects \ GenericArriba \ snapshot_mk \ GenericPre_V009 \ siemens \ siemenscpp \ src \ vp \ coinmon \ gps _utils.cpp: 112: l: Note 960: Violates MISRA Required Rule 87, only preprocessor Statements and comments before 'finclude' d: \ usr \ projects \ GenericArriba \ snaps ot_mk \ GenericEre_V009 \ siemens \ siemen3cpp \ src \ vp \ common \ gps _utils.cpp: 113: 1: Note 960: Violates MISRA Required Rule 87, only preprocessor statements and comments before '#include'

Table 1: Example of a PC lint report (Inr file)

Depending on the size of the underlying project, the source files it contains, and the content of the so-called policy files, these reports can become very large. B. well over 100,000 lines of text or several megabytes in size.

For example, with the help of a Perl script, this report will be transformed into a first step by summarizing identical message types and creating one

In summary, a so-called Ins file was created, the content of which is shown in Table 2 below. The extension "Ins" stands for lint summary.

506 2 Constant value Boolean 527w 1 ünreachable 529 5 Symbol ^■ ... '(...) not subse uently referenced 534w 22 Ignoring return value of function (compare wit, ..) 537w 8 Repeated include file' ... '544w 3 endif or eise not followed by EOL 550w 1 symbol '...' (...) not accessed 570w 1 Loss of sign (...) (... to ... 613w 3 Possible use of null pointer '. . 'in ... argument to Operator 632w 35 Assignment to strong type' ... in context: ... 633w 11 Assignment from a strong type ... 'in context: ... 634w 11 String type mismatch (type' .. ') in e uallty or conditional 638w 2 Strong type mismatch for type '...' in relational 639w 15 Strong type mismatch for type '...' in binary Operation 641w 5 Converting enum to int 668w 1 Possibly passing a null pointer to function '...', 713i 1 Loss of precision (...) (... to) 715i 10 Symbol '...' (...) not referenced 725i 2 Expected positive indentation rom ... 732i 2 Loss of sign (...) (... to ...) 734i 2 Loss of precision (...) (... bits to ... bits) 740i 1 ünusual pointer cast (incompatible indirect types) 744i 2 switch Statement as no default 750i 2 local macro '...' (...) not referenced 752i 2 local declarator '...' (...) not referenced 762i 5 Redundantly declared symbol '...' previously declared at ... 766i 5 Include of header file ... not used in module ... 792i 3 void cast of void expression 818i 5 Pointer para eter '...' (-) could be declared ptr to const 829i 1 A + headerwarn Option Was previously issued for header '. .. '

(830i 34) Location cited in prior message 912n 13 Implicit binary conversion from ... to ... 917n 26 Prototype coercion (...) ... to ... 957n 6 Function '' defined without a prototype in scope 960n 30 Violates MISRA Required Rule ..., 961n 9 Violates MISRA Advisory Rule ..., ... 970n 344 Use of modifier or type '' outside of a typedef 97In 27 Use of 'char' without 'signed' or 'unsigned'

1512w 6 destructor for base class '' (...) is not virtual

1717i 19 empty prototype for function declaration, assumed '(void)'

1904n 181 Old-style C comment

1923n 15 macro '...' could become const variable

1924n 25 C-style cast 126 arning 43 Info 455 Note 6 Warning 19 Info 221 Note 870 Total Table 2: Compressed form of a PC Lint report (Ins file)

In contrast to the original PC-Lint reports, the generated, compressed reports are significantly smaller and structurally clearer. They form the starting point for the following steps of the procedure.

The following section is particularly interesting for so-called unit tests. Code checker tools such as PC-Lint are also able to perform system tests across module boundaries perform. The messages that are generated are treated in the same way as the messages in the context of unit tests.

Another feature of the compression script is the elimination of redundant messages. A redundant message can e.g. are generated by including the same header file multiple times. The summary created only counts clear messages. Other messages, such as the message 830 in Table 2 is redundant, since it is a message but two reference points, namely on the definition and usage parts. They refer to related code in the source file, but do not index a new message.

In addition to generating diagrams for each individual source file examined, the method offers diagrams that represent a summary for a number of related source files, the so-called transitive envelope. The process also enables

Generation of different diagram types. Examples are a snapshot of the current status or a comparison of two different versions of a source code status. In addition to the lns files for individual source files, the script also generates the so-called "transitive envelope" of the lns files contained therein for a set of source files defined by the directory or project structure. In other words, if a project consists of 3 cpp files and there are 3 lnr and 3 lns files, a file called tc.lns is created at project level, one

Summary of the contained lns files. The prefix "tc" stands for Transitive Closure. This transitive envelope enables a quick overview of the status of the source code being examined on a level above that of individual files. The PC-Lint reports compressed by the Perl script are now converted into subject-like evaluation diagrams.

Before that, however, some basic information about PC-Lint, which is helpful for understanding the following description.

PC-Lint divides its reports into 4 categories: • Errors, • Warnings, • Information and • Notes.

Within these categories, a distinction is made between the programming languages C and C ++.

In total, the messages from PC-Lint can be assigned to 8 different groups.

FIG. 1 shows a schematically illustrated fan-like evaluation diagram (fan diagram), in which these categories are shown in the form of sectors in an angular range of 180 ° in vertical form or, with the o'clock position and the 1- Clock position the message types of the most important problem type E (errors), between the 1 o'clock position and the 3 o'clock position the message types of the second most important problem type (warnings), between the 3 o'clock position and the 5 o'clock position the message types of the third most important problem type I (info) and between the 5 o'clock position and the 6 o'clock position the message types of the last most important problem type N (notes) are classified.

The differences in the angular ranges between E and N on the one hand and W and I on the other hand roughly reflect the differently large integer ranges that are used to number the PC-Lint messages of the different categories. The graphic representation presented is based on the version of the PC-Lint reports compressed by the Perl script, the so-called * .lns files. This means that a diagram is generated for each source file, eg * .cpp, and the associated * .lns file.

The .lns files contain messages of the same type, i.e. with identical ID, together and sum up their occurrences. These values are, for example, in the schematic, graphic visualization using z. B. red lines. The 10 logarithm is used as a function in order to be able to cover the large range of values well. In addition, it is achieved that several, side-by-side, fan-like evaluation diagrams can be compared qualitatively very easily. The number of concentric circular lines and thus the scale is configurable and the default value is predefined with "3". In the exceptional case of the value "1", a deviation from the 10-logarithm is made for reasons of clarity and a short line is nevertheless displayed. The number of z. B. red lines represent the occurring message types in the compressed PC-Lint report, the length of the line the frequency of their occurrence. If the end point of a line lies outside the displayable range, the line is simply cut off.

For the actual conversion into a graphical representation, for example, a Perl script called lns2plot is used, which receives an existing .lns file as input and an intermediate result. fan file for the fan-like evaluation diagram. This . Fan file is now processed by a graphics program, for example by the gnuplot program as a gnuplot program, and either the finished fan diagram is displayed in a new window or in a format to be defined (* .png, * .pbm, *. gif, etc.) stored in a file.

In general, the subject-like evaluation diagrams provide the viewer with a quick, qualitative overview Status of the associated source code, e.g. B. to convey a single file, sub-project or project. Always consult the associated .Ins file for detailed information on exact numbers and error numbers.

Optionally, it is also possible to generate a heading with the associated file name and a time stamp as a signature, which reflects the time of the diagram generation.

The following briefly describes which commands are required at the shell level in order to generate and display such fan-like diagrams or fan diagrams under RedHat and Cygwin / Windows, for example.

Cygwin / Windows:

Generation of such a fan-like diagram and display in a window:

$ lns2plot -style fan -type xll -noplot adas.lns

$ startx

$ gmiplot

gnuplot> load "adas.lns .fan"

RedHat Linux / Cygwin / Windows: Generation of a fan diagram and saving in a file in png format:

$ lns2plot -style fan -type png adas.lns

As can be seen from the above command sequences, the type option enables the user to control whether the generated diagram is displayed (xll) or whether it should be written to a file in a defined format (png). The style option enables the selection of a diagram type (eg fan). Another characteristic of the fan diagrams is that the subjective impression of the frequency of messages is not lost when the lines are aligned with the zero point when the diagrams are reduced, for example, for display in thumbnail form.

FIG. 2 shows a diagram for comparing two source code versions. In order to generate this variant of the original fan diagram, the previously described Perl script lns2plot advantageously offers an option "vs" (Versus) to compare two different versions of the same source code level. This form of representation is particularly suitable for observing the development of source code over time. The focus of this fan diagram variant is on the representation of the change from a source code version of version x to a source code version of version y.

The fan-like diagram of Figure 2 is made up of two

Semicircles built up, whereby the left semicircle concentrates on the improvements VB compared to the source code level to be compared, the right semicircle on the other hand represents the deteriorations VS or unchanged states UZ. For reasons of clarity, positive and negative changes are distributed over the two semicircles.

The crosses without a line shown in the diagram represent minimal changes, the extent of which is so small that they cannot be represented by a visible line.

Appropriate coloring can make negative and positive changes particularly clear. For example, green crosses mean minimal improvements, red crosses mean minimal deteriorations and green and red lines represent significant changes in positive or negative direction. The length of the lines should give a quantitative impression of this change. The points colored blue, for example, finally in the right semicircle represent stagnating states, that is to say none with regard to these source code messages

Changes in the number of reported errors result.

Again, this fan diagram focuses on giving a qualitative impression as quickly as possible of how an underlying source code version has changed compared to a version to be compared. This form of fan diagram also applies that it can be generated not only for individual source files, but also for sets of source files that result from the underlying directory or project structure.

The position of the lines and the representation of the dots contain the meaning, the coloring is only an aid on media that can display the diagrams in color.

In addition to the singular representation of individual fan diagrams, it is also possible to view the fan diagrams for an underlying software project in HTML form using any browser. The structure of the HTML pages corresponds to the project or

Directory structure of the software project to be examined. Navigation within the diagram hierarchy is implemented using HTML links.

Another script can optionally be used to present the generated diagrams in HTML format. With the help of this representation, the diagrams can be viewed with any browser and also navigation in the hierarchy of the generated diagrams using HTML links.

Conceptual expansions of the method consist in using the VRML technology to generate the fan diagrams display three-dimensional form, for example to make it zoomable, as well as the possibility of navigating from the diagram directly to the relevant source code location.

The advantage of the method described is that

Possibility that the viewer of the fan diagrams can get a very quick, qualitative overview of the state of the source code examined, which is not possible in the approach by manual evaluation of the textual information. The availability of diagrams for a number of source files - see Transitive Shell - or for an entire project further underlines the advantage.

Furthermore, the method makes it possible to obtain a purely visual, quick impression of the change in a system by displaying the change between two different system states. In addition, the procedure is largely independent of the code checker tools that provide the underlying data stock due to the aforementioned requirements.

Claims

claims

1. Procedure for evaluating code reviewer reports,

- in which a code reviewer report (lnr) is compressed with messages categorized according to problem types, whereby identical message types are summarized and a compressed report (Ins) is formed, and

- In which a fan-like diagram is formed from the compressed report in such a way that lines are arranged around a common center point (MP), the message types being converted into angular coordinates (WK) according to problem types and frequencies of the message types being converted into length coordinates (LK) of the lines ,

2. The method according to claim 2,

- In which the frequencies of the message types are logarithmized when calculating the length coordinates (L) of the lines and, in the case of frequency one, a minimum length of the length coordinates is used instead of zero.

3. The method according to claim 1 or 2,

- in which the message types of the most important problem type (errors) between the o'clock position and the 1 o'clock position, - in which the message types of the second most important problem type (warnings ),

- in which the message types of the third most important problem type (info) and between the 3 o'clock position and the 5 o'clock position

- in which the message types of the most important problem type (notes) are classified between the 5 o'clock position and the 6 o'clock position.

4. The method according to any one of the preceding claims,

- in which the message types within the problem types are classified according to the language (C, C ++) of the source code.

5. The method according to any one of the preceding claims,

- which generates a heading with the associated file name and a time stamp as a signature that reflects the time of the diagram generation.

6. The method according to any one of the preceding claims,

- in which the generated fan-like diagrams are reduced or enlarged.

7. The method according to any one of the preceding claims,

- which uses a code reviewer report from a set of related source files.

8. The method according to claim 7, - in which the source files are located in different directories and the fan-like diagrams are connected to one another via links in accordance with the directory structure.

9. The method according to any one of the preceding claims, - in which navigation from the diagram takes place directly to the relevant source code location.

10. Procedure for evaluating code reviewer reports,

- in which a current and a previous code reviewer report is compressed with messages categorized according to problem types, a summary of identical message types taking place and a respective compressed report being formed, and

- in which a fan-like diagram is formed from the compressed reports in such a way that improvements over previous source code in a left semicircle and deteriorations over a right semicircle the previous source code or unchanged states, where crosses represent minimal changes, lines represent significant changes in positive or negative direction, and dots represent stagnating states.