KR20060113168A - Source code analysys for source code inspector - Google Patents

Abstract

A method for analyzing source codes for application of a standard coding rule is provided to verify whether the source codes are made according to the standard coding rule in a cooperated software development environment by analyzing the source codes and make each developer develop the software based on the standard coding rule. A rule database is formed by discriminating the standard coding rules into four types including an outer appearance, name, explanation, and appendix forming rule for the source code(S31). The target source code is inputted and analyzed by using four types. It is checked whether an outer appearance of the analyzed source code follows the outer appearance forming rule or not, and a result is output. It is checked whether naming formation of the analyzed source code follows the name forming rule or not, and the result is output. It is checked whether an explanation of the analyzed source code follows the explanation forming rule or not, and the result is output. It is checked whether an appendix of the analyzed source code follows the appendix forming rule or not, and the result is output.

Description

SOURCE CODE ANALYSYS FOR SOURCE CODE INSPECTOR}

1 is a diagram illustrating a series of processes leading to software development, verification, and completion according to the present invention.

2 is a block diagram showing a configuration of a source code analysis system according to the present invention.

3 is a diagram showing an embodiment of an interface screen of a source code analysis system according to the present invention;

<Explanation of symbols for the main parts of the drawings>

10: Source Code 20: Source Code Analyzer

21: Creation Rule (DB) 30: User Interface

210: external configuration analysis module 220: naming (naming) analysis module

230: comment analysis module 240: annex analysis module

The present invention relates to a source code analysis method for verifying whether each developer has performed a corresponding software development based on standard software writing rules in an environment in which a plurality of developers participate and jointly develop software.

In an environment where multiple developers participate and develop software jointly, each developer can share the software and develop it, and each of the developed software can be organically integrated to implement one complete software.

However, in such a software development environment in which a large number of developers participate, each developer develops a shared software based on their own unique characteristics, and thus, a problem arises when finally combining the respective software organically.

This is because, despite the fact that there are standard software writing rules, the application of the rules appears in different ways due to different levels of understanding, mistakes, and personality among developers. In this case, since the readability of the code is reduced, joint software development is difficult.

In other words, in a software development environment in which a large number of developers jointly participate, standard software writing rules are provided to minimize the above problems, but despite this, different levels of understanding and mistakes by developers, and standard software writing rules are provided. Insufficient knowledge of the standard leads to difficulties of co-development, and re-use of existing software that does not apply the standard software writing rules makes it difficult to observe the standard software writing rules. There is a problem that fall.

Therefore, there is a need for a method that can analyze the code during development or after development and determine whether the developed software has adhered to the standard software writing rules promised to each other.

In the software development environment in which a large number of developers participate, the present invention analyzes the code during development or after development, and verifies whether it is written according to the standard software writing rules, and each developer uses the software according to the standard software writing rules. Its purpose is to provide a source code analysis method for development.

In addition, the present invention can be detected even if the software is applied to different standard software writing rules, and suggests that it can detect and correct the violation, it is possible for different developers to complete the software applying the same standard software writing rules The purpose of this study is to provide a source code analysis method that can provide an environment for developing software with legibility.

Source code analysis method of the present invention for achieving the above object comprises the steps of constructing a standard software creation rule database, analyzing the source code of the development software to be analyzed, the standard software creation rules and the analyzed source Comparing the code to analyze the compliance of the writing rule, and outputting a result for compliance with the writing rule: characterized in that comprises a.

In addition, in the source code analysis method according to the present invention, the standard software creation rule is characterized by verifying the classification by a plurality of types based on the characteristics of the rule.

In addition, in the source code analysis method according to the present invention, the standard software writing rule is characterized by classifying into four types of appearance configuration, naming, description, and other supplementary rules based on the characteristics of the rule.

In addition, in the source code analysis method according to the present invention, the appearance configuration is characterized in that it includes a definition of the position, shape, spacing, etc. that the sentence is placed.

In addition, in the source code analysis method according to the present invention, the naming type includes a definition of a rule for naming each token (TOKEN) used in a program such as a file name, a variable name, a function name, a constant name, and the like. It is done.

In addition, in the source code analysis method according to the present invention, the description type is characterized by suggesting a compliance term related to the position or form when using the description.

In addition, in the source code analysis method according to the present invention, the annex type is characterized in that it includes a definition of the remaining rules, except the appearance configuration, naming, description.

In addition, in the source code analysis method according to the present invention, for verifying the writing rule for each type; Appearance further comprises a configuration analysis module, naming analysis module, comment analysis module, annex analysis module.

In addition, in the source code analysis method according to the present invention, the output of the analysis result is characterized in that made on the basis of a user interface screen.

In the source code analysis method according to the present invention, the output of the analysis result is characterized in that it comprises at least a project management window, an edit window, a result output window based on the user interface screen.

In addition, in the source code analysis method according to the present invention, the output of the analysis result is characterized in that it represents the statistical data and the function call relationship for the target file.

When described in detail with reference to the accompanying drawings an embodiment of the source code analysis method of the present invention made as follows.

As described above, in the development of software in which a large number of developers participate, the standard software is prepared to solve various problems that may occur when each developer organically integrates their respective software into one completed software. It is a system that selects rules in advance and verifies whether each developer has carried out a shared software development by complying with the corresponding writing rules.

In other words, it includes a function that automatically checks the compliance of the source code writing rules, and when used as a tool to supplement the peer review process that is currently manually performed, it is possible to use the source code writing rules and Detect related source code defects.

The software development process usually involves requirements analysis, design, coding, testing, and distribution. This process does not end with a single pass, but rather when the fault occurs at a particular stage, the previous stage (s) is performed again. The maintenance process will be repeated.

The ultimate goal of software development is to improve the quality of the software, and each step is based on its own methodology. The software testing process is also a step in this effort, assuming faults that can occur during software development and identifying them as activities.

Software testing is largely divided into static testing (static analysis) and dynamic testing (dynamic analysis).

Static testing is the task of detecting potential errors by closely analyzing the appearance of source code, and is testing that does not need to be associated with program execution.

As in the present invention, it is an example of static analysis that adds a rule to be newly adhered to the syntax of the existing C language so that all programs maintain the appearance consistency and then checks the compliance of the rule. .

As such, static testing is mostly based on a set of programming rules, or coding rules. In addition, static testing involves checking for defects by following code in order of execution without actually executing the program, and includes generating various statistics at the source code level.

Dynamic testing refers to the task of finding a problem with a program by actually executing the program and then observing how it is executed, usually with a test case consisting of input data and output data.

The present invention mainly includes rules related to appearance for enhancing program readability, and code inspection through this is a kind of static analysis, which is an early stage for software testing. Increasing readability by keeping the programming coding style consistent is a means of improving the quality of the software by reducing the cost of future maintenance and ultimately facilitating error detection.

Currently, code verification is performed by hand in the form of peer review, using a checklist for error checking. The present invention is a tool to complement the code verification that is performed by hand, by reducing the inspection time significantly by automating the items that can be automated in the error check list to be able to perform the verification operation more accurately. In addition to coding rules, statistics and function call relations of target files are shown to be used as basic data for code analysis.

1 shows a source code analysis process according to the present invention. The first step S10 is a step in which a standard software (SW) writing rule is prepared in advance, and each developer is familiar with the written standard software writing rule. The second step (S20) is a step in which each developer shares and executes software development. At this stage, each developer must comply with the above standard software writing rules, but in reality, it is difficult to fully comply with the software writing rules based on the difference in understanding of the rules between the developers, or the personal characteristics of the developers.

The third step S30 is a step of verifying the source code. In other words, it is a series of processes for automatically checking whether each of the software complies with the writing rules by using the software written by each developer as input and using the standard software writing rule as a database. The first step S31 is to database the standard software creation rule. In other words, by making a database of standard software writing rules written in the form of a normal document in the first step S10, it provides a basis for automatically verifying whether the developed software complies with the writing rules. . The next step (S32) is to analyze the software developed by each developer, and compare the analyzed source code with the database-based standard software writing rules. The next step (S33) is to determine whether the corresponding software complies with the standard software writing rules as a result of the comparison, and output the results to each developer to modify and complete the software based on the standard software writing rules Steps to make it possible.

The fourth step (S40) is a step in which the development of software consistently applying the same coding rules that completely comply with the standard software creation rules through the above verification, modification and supplementation process is completed.

2 shows a configuration of a source code verification system according to the present invention. As an example, the source code verification system of the present invention used Windows 98, 2000, XP, etc. as the operating system in the development environment, the compiler used Visual C ++ 6.0, and the library (source code analyzer) was Lex [Flex], Yacc [Bison], a library (screen interface), is based on Visual C ++ MFC. In addition, the operating environment of the source code verification system according to the present invention can be used as the operating system Windows 98, 2000, XP, etc., the hardware is based on more than 256M RAM.

Referring to FIG. 2, the source code verification system according to the present invention includes a source code 10, a source code analyzer 20, and a user interface 30. The source code analyzer 20 includes the standard software creation rule (DB) 21 described above. In addition, the source code analyzer 20 may be configured to include a module for performing analysis of the corresponding source code for each type of standard software writing rule. For example, in order to efficiently verify the standard software writing rule, the configuration and naming may be performed. Assuming that the test is divided into four types such as composition, description, and by-laws, the external configuration analysis module 210, naming analysis module 220, comment analysis module 230, and by-law analysis module 240 for each Include.

3 shows an example of the user interface 30. Looking at this user interface, it can be seen that the project management window 100, the edit window 200, and the result output window 300 are configured. The project management window 100 is for managing a work target, and expresses information about a target file currently being edited, the edit window 200 expresses a corresponding source code, and the result output window 300 displays standard coding rules. Whether it is applied well, especially if it violates the writing rules, the content is expressed.

Table 1 below shows an example of categorizing standard software writing rules by type. In the present invention, the standard software writing rules are divided into four types: appearance configuration, naming (naming), description, and other (additional rules). The appearance structure is the definition of the position, shape, and spacing where the sentence is placed, and enables the effective review of the logical flow in the future review of the program.

Appearance * Define where the sentence is placed, its shape, its spacing, etc. * In the future, it is possible to effectively review the logical flow when reviewing the program. Naming (naming) * Rule to name each token (TOKEN) used in the program such as file name, variable name, function name, and constant name. Description * Provides instructions regarding the location and format of the description. * In many cases, there is a lack of explanation by the code itself, so the explanation should be used to help the readers of the source code read. Etc * In addition, the program must be followed.

Table 2 below shows an example of the detailed rules regarding the composition of the appearance: it can be seen that it defines the structure of the sentence as well as the position, form, and spacing of the sentence.

number Rule content 1-1 switch statement must include default case and default must include break statement 1-2 Line breaks in the middle of formulas prevent logic from breaking 1-3 Position if leading to next line in function call statement 1-4 Order of components in the file 1-5 Infinite loop search .... .... 1-N ****

The detailed rules of appearance configuration include indentation, limiting the depth of control and loop statements, moving the next line of conditional statements within control statements, using comments within control and loop statements, using default statements in switch statements, and simple assignment statements. '=' Sorting, whitespace in lists, line breaks in formulas, next line position in function invocations, sorting when declaring variables, ordering of components in files, using blocks at the beginning of control and loop statements, infinite loops Rules about recursive calls, the use of one statement per line, and so on.

For example, in the case of indentation rule, the indentation rule should be indented at the level of each line. This is for the purpose of improving program readability. The distinction between error and warning is error. As a reference, define rules such as specifying the size of a tab through options.

The rules of appearance outlined above are actually things that may be dependent on a particular program and should not be limited to what is described here. However, because of the premise of the variety of coding rules used in relation to specific software development, the details of standard software writing rules can be changed adaptively. Although changed, it is too obvious in the art that source code verification will be performed based on the method proposed by the present invention.

Table 3 below shows an example of the detailed rules for naming. The naming convention is the convention for creating the names of each token (TOKEN) used in the program, including file names, variable names, function names, and constant names. This makes it possible to grasp the meaning only by name.

Detailed rules for naming include the length of variable and function names, the use of '_' in file names, the use of '_' in variable names, the use of lowercase letters as the first letter of variable names, and the rules for multi-purpose variable names. -purpose variable consists of [range] [type] [variable name]], constant name should be capitalized, first letter of function should be capitalized, '_' not allowed in function name, etc. .

Also, function name naming conventions (function names are organized in the order of [layer] _ [module] _ [function name]]; function and variable names must not be capitalized only; no numbers can be used in formulas; Variables use names that imply true or false), naming conventions for enumerated constants (enumerate enum members have the same prefix or suffix), unused local variables (unless local variables are used within a function Rules for unused global variables (must not have unused global variables within a function), uncalled functions (defined functions must be called more than once), and so on.

number Rule Description 2-1 The name is long enough to describe the identity and role of each entity. 2-2 In case of multi-purpose variable, it is composed in order of [range] _ [type] _ [variable name]. 2-3 Function name consists of [layer] _ [module] _ [function name] 2-4 Do not use function / variable names that consist only of uppercase letters 2-5 If you use numbers in assignments, comparisons, etc., use constant names or ordered types with meaningful names instead of numbers. 2-6 Names of ordinal members have the same prefix or suffix 2-7 Find unused variables within a function 2-8 Detect unused variables among global variables 2-9 Detect Uncalled Functions .... .... 2-M ****

Table 4 below shows an example of the detailed rules of explanation. The comment rule sets out the requirements regarding the location or form of the comment. In this way, the code itself can cope with a lack of explanation, and the description can be used as a basis for helping the reader to understand the source code.

For detailed rules about comments, use "//" to write comments on a single line, "/ ** /" to write comments on more than one line, or comment at the end of a sentence only in special cases. Define rules such as declaring variables in the case where comments can be written on the same line as a code statement, allowing only at the end of a loop statement, or using end-line descriptions only in certain cases. .

number Rule Description 3-1 End-line comment is available only in certain cases-variable declarations, version information, end of loop .... .... 3-L ****

Table 5 below shows an example of the detailed rules for additional rules. It includes a number of rules that do not belong to the type of appearance, naming, description, etc. described above.

number Rule Description 4-1 Header file does not include other header files 4-2 goto can be used for time-critical code 4-3 If there is an if statement in the statement, do not compare the variable with TRUE 4-4 The type definition can be selected from: UNIT8, UNIT16, etc. 4-5 Numbers can't appear directly in formulas 4-6 user-defined data structure only allows 3-step or less nesting 4-7 Use header files to manage data structures and global variables 4-8 Use a header file to manage #ifdef definitions in batches .... .... 4-M ****

This includes prohibiting the inclusion of header files in header files, rules on the prohibition of using goto statements, prohibiting the use of TRUE and FALSE in conditional statements, and allowing permission to redefine integers. The definition of constants, the prohibition of inclusion of Bmp data (that is, separate source code from data files such as bmp), nesting restrictions when declaring structures, type definitions and global variables within source files Information about prohibition of use, information about prohibiting the use of #ifdef, #else, and #endif, information about managing #define constants, prohibiting the use of 0,1 in #if and #elif statements, and the number of lines per file. Defines the limit, the limit on the number of characters per line, and the unknown error.

As described above, the standard software writing rules are divided into four types for source code verification, and detailed rules for each type are applied to determine whether the corresponding software complies with the writing rules.

Based on the example of standard software writing rules described above, the operation of the source code verification system of FIGS. 1 and 2 will be described in more detail.

Each developer develops a shared software and source code 10 of the developed software is provided as input to the present verification system. The user interface 20 provides an interface between the user and the verification system based on the interface screen as illustrated in FIG. 3.

The source code analyzer 20 has the above-described writing rule 21 built in a database. The source code analyzer 20 may include an analysis module for each type of the writing rule for efficient verification.

The input source code 10 is analyzed by the external configuration analysis module 210, the external configuration of the software (parsing). The analyzed source code appearance configuration is compared with the appearance configuration rule of the preparation rule 21 (see Table 2). The comparison result of the appearance configuration rule of the creation rule 21 and the analyzed source code appearance configuration is displayed in detail in the result output window 300 with respect to the contents that violate the rule.

The input source code 10 is analyzed by the naming analysis module 220 of the naming configuration of the software. The analyzed source code naming scheme is compared with the rules of writing (see Table 3). The result of comparing the naming configuration rule of the creation rule 21 and the analyzed source code naming configuration is displayed in detail in the result output window 300 with respect to the violation of the rule.

The input source code 10 is analyzed by the comment analysis module 230, the composition of the comment of the software. The analyzed source code description constructs are compared with the composition rules (see Table 4). The comparison result of the composition of the composition rule 21 and the analyzed source code description structure is displayed in detail in the result output window 300 with respect to the contents that violate the rule.

The input source code 10 is analyzed by the annex analysis module 240 and other components of the software. The analyzed source code structure is compared with the composition rules (see Table 5). The comparison result between the other supplementary provisions of the preparation rule 21 and the analyzed source code configuration is displayed in detail in the result output window 300 with respect to the violation of the rule.

Such verification results are notified to each software developer, and each developer can revise and supplement the violation of the rules based on the written rules based on the verification results.

Then, by repeating the above verification process, if a violation of the standard software writing rules is not found, the organic integration of the corresponding software is performed.

Of course, after the organic integration of the software shared by a number of developers, the completed software is subjected to the above verification process, and finally, the software that completely complies with the rules of writing will be developed and completed.

According to the present invention, even if software having different standard software writing rules is applied, it automatically checks whether the source code complies with the writing rules and provides the result, thereby making it easy to modify and supplement the developed software.

Therefore, it can help to save time and efficiency of software development, and in particular, it is possible to produce software with different standard software writing rules, thus providing a highly readable software development foundation.

In addition, the application of consistent standard software writing rules can maximize the efficiency of organic integration, modification, complementation, and verification among shared software.

Claims (12)

Constructing a standard software writing rule database, analyzing source code of the development software to be analyzed, comparing the standard software writing rule with the analyzed source code, and analyzing whether the writing rule is observed; Outputting a result of compliance with the rule: Source code analysis method for applying a standard coding rule, characterized in that comprises a. The method of claim 1, wherein the standard software writing rule is classified and verified by a plurality of types based on the characteristics of the rule. The source code analysis of claim 1, wherein the standard software writing rule is classified and verified into four types of appearance configuration, naming, description, and other supplementary rules based on the characteristics of the rule. Way. 4. The method of claim 3, wherein the appearance configuration includes definitions of positions, shapes, spacings, etc., in which sentences are placed. 4. The method of claim 3, wherein the naming type includes a definition regarding a rule for naming each token (TOKEN) used in a program such as a file name, a variable name, a function name, a constant name, and the like. Source code analysis method. 4. The method according to claim 3, wherein the description type presents a compliance term related to the position or form when using the description. 4. The method of claim 3, wherein the supplementary type includes a definition about a writing rule other than the appearance configuration, naming, and description. 4. The method of claim 3, further comprising: for verifying the writing rule for each type; Source code analysis method for applying a standard coding rule, characterized in that it further comprises a configuration analysis module, naming analysis module, comment analysis module, annex analysis module. The method of claim 1, wherein the output of the analysis result is based on a user interface screen. The method of claim 1, wherein the output of the analysis result comprises at least a project management window, an edit window, and a result output window based on a user interface screen. The method of claim 1, wherein the output of the analysis result indicates a relationship between statistical data and a function call with respect to a target file. The standard software writing rules are divided into four types of appearance rules, naming rules, descriptive rules, and by-laws for the corresponding source code to construct the rule database, and the source code to be analyzed. Classifying and analyzing the source code into four types of appearance configuration, naming configuration, description composition, and by-laws, and determining whether the analyzed source code appearance configuration violates the appearance configuration rule, and as a result, Outputting, determining whether the analyzed source code naming scheme violates the naming convention and outputting the result, whether the analyzed source code naming scheme violates the prescriptive rule. Determining and outputting the result, wherein the analyzed source code addendum violates the description addendum Determining whether or not the data is outputted and outputting the result. Source code analysis method for applying a standard coding rule, characterized in that it comprises a.

Images