Methods, apparatus, equipment and media for code cloning risk assessment

Abstract

This application relates to a method, apparatus, device, and medium for code cloning risk assessment. The method includes: acquiring project information and clone lineage data; extracting risky clone features from the project information; constructing a clone risk assessment framework; using the clone risk assessment framework, and based on the project information and clone lineage data, assessing the clone risk level corresponding to each code clone pair; and training a pre-constructed XGBoost model based on the clone risk level and risky clone features, so that the XGBoost model can assess the code cloning risk level. This method enables code cloning risk prediction without relying on historical information.

Description

Technical Field

[0001] This application relates to the field of code cloning technology, and in particular to a method, apparatus, equipment and medium for code cloning risk assessment. Background Technology

[0002] Code cloning is a common phenomenon in software development, referring to the reuse of the same code snippets in different parts or projects. However, the quality and security of cloned code are often difficult to assess directly, and the risks are often only discovered when cloned code has already caused software errors, leading to high software maintenance costs. Therefore, how to distinguish between cloned code that poses a risk to software has become an important issue in the current software development field.

[0003] Existing technical solutions primarily focus on research into the correlation between code cloning and software errors. These studies are often conducted after cloning incidents have occurred, analyzing the correlation between bug fixes and factors associated with code cloning within the project. However, the results of these studies can only provide programmers with a guide to identify risky cloning; ultimately, programmers still need to rely on their understanding of the project and their programming experience to make the distinction.

[0004] For example, existing technologies utilize Bayesian networks to predict the consistency maintenance requirements of code clones. They extract all cloning operations and elements potentially related to consistency maintenance requirements from the software system's evolution process, construct a Bayesian network, and train it. This method can accurately identify whether cloned code requires consistency maintenance and which cloned code does.

[0005] Another traditional technique proposes a model for assessing the severity of cloning hazards. This model extracts information from the cloning's evolutionary history, including past modifications, bug fixes, and consistency maintenance, detecting delayed consistency changes (changes of the same type and content committed in different commit operations). It uses four quantitative indicators to measure the degree to which cloning harms software quality or poses potential dangers, classifying them into four hazard levels. This work classifies harmful clones based on their evolutionary history, and this hazard level classification can, to some extent, distinguish harmful clones.

[0006] However, these existing technical solutions all have certain limitations. Focusing only on the consistency aspect of code cloning risks or harms cannot provide a comprehensive prediction of code cloning risks. While the proposed models for assessing the severity of cloning harm can distinguish harmful clones to some extent, the methods for assessing cloning harm are based on the evolutionary history of cloning, where cloned code may have already caused harm, and programmers still need to bear the cost of bug fixing. Summary of the Invention

[0007] Therefore, it is necessary to provide a method, apparatus, equipment, and medium for assessing code cloning risks in response to the aforementioned technical problems.

[0008] A code cloning risk assessment method, the method comprising:

[0009] Obtain project information and clone lineage data, and extract risky clone features from the project information; the risky clone features include: code features, developer features, and project features.

[0010] Construct a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistency modification delay index;

[0011] Using the aforementioned cloning risk assessment framework, the cloning risk level of each code clone pair is assessed based on the project information and cloning lineage data.

[0012] Based on the cloning risk level and risk cloning characteristics, a pre-built XGBoost model is trained so that the XGBoost model can evaluate the code cloning risk level.

[0013] In one embodiment, the method further includes: setting multiple star count ranges from GitHub based on the number of stars; randomly crawling open-source Java projects within each star count range, and extracting the clone lineage at the function granularity using a clone lineage extraction tool to obtain project information and clone lineage data; and storing the project information and clone lineage data in a database.

[0014] In one embodiment, the code features include: whether the function names of the code clone pairs are the same, whether the code snippets of the code clone pairs are exactly the same, whether one of the two code snippets in the code clone pair is a functional code snippet and the other is a test code snippet, the number of historical changes to the corresponding line of the clone code pair, and the number of code snippets in the submitted code that are clones of each other.

[0015] In one embodiment, the developer characteristics include: information on the code submitter's project participation experience, whether the code submitters of the cloned code snippets are the same, and the number of historical collaborating developers of the cloned code snippets.

[0016] In one embodiment, the project features include: code clones of the project.

[0017] In one embodiment, the risk level is further defined as follows: when the number of modifications is 0 or the number of modifications is greater than 0 and the proportion of modifications is equal to 0, the risk level is 0; when the number of modifications and the proportion of modifications are both greater than 0 and the time interval between modifications and submissions is equal to 0, the risk level is 1; when the number of modifications, the proportion of modifications, and the time interval between submissions are all greater than 0 and the consistent modification delay is equal to 0, the risk level is 2; and when the number of modifications, the proportion of modifications, the time interval between submissions, and the consistent modification delay are all greater than 0, the risk level is 3.

[0018] In one embodiment, the method further includes: training a multi-class XGBoost model using the risk clone feature as an independent variable and the clone risk level as a dependent variable.

[0019] A code cloning risk assessment device, the device comprising:

[0020] The data acquisition module is used to acquire project information and clone lineage data, and extract risk clone features from the project information; the risk clone features include: code features, developer features, and project features.

[0021] The assessment framework construction module is used to build a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistent modification delay index.

[0022] The risk assessment module is used to assess the cloning risk level of each code clone pair based on the project information and cloning lineage data using the cloning risk assessment framework.

[0023] The training module is used to train a pre-built XGBoost model based on the cloning risk level and risky cloning characteristics, so that the XGBoost model can evaluate the code cloning risk level.

[0024] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps:

[0025] Obtain project information and clone lineage data, and extract risky clone features from the project information; the risky clone features include: code features, developer features, and project features.

[0026] Construct a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistency modification delay index;

[0027] Using the aforementioned cloning risk assessment framework, the cloning risk level of each code clone pair is assessed based on the project information and cloning lineage data.

[0028] Based on the cloning risk level and risk cloning characteristics, a pre-built XGBoost model is trained so that the XGBoost model can assess the code cloning risk level.

[0029] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0030] Obtain project information and clone lineage data, and extract risky clone features from the project information; the risky clone features include: code features, developer features, and project features.

[0031] Construct a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistency modification delay index;

[0032] Using the aforementioned cloning risk assessment framework, the cloning risk level corresponding to each project is assessed based on the project information and cloning lineage data.

[0033] Based on the cloning risk level and risk cloning characteristics, a pre-built XGBoost model is trained so that the XGBoost model can evaluate the code cloning risk level.

[0034] The aforementioned code cloning risk assessment method, apparatus, equipment, and medium first acquire project information and cloning lineage data, thereby extracting risky cloning features from the project information. Then, based on the relationship between code modification and code cloning risks, a cloning risk assessment framework is constructed to assess the project's risk. This method eliminates the need for risk events to occur and relies on developer experience. Subsequently, based on the cloning risk assessment framework, risk assessments are performed on code clone pairs. Based on the assessed risk level and the extracted risky cloning features, an XGBoost model is trained, enabling the XGBoost model to evaluate the code cloning risk level. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a code cloning risk assessment method in one embodiment;

[0036] Figure 2 This is a flowchart illustrating the code cloning risk assessment steps in one embodiment;

[0037] Figure 3 Here is a diagram of the cloning risk assessment framework in another embodiment;

[0038] Figure 4 This is a structural block diagram of a code cloning risk assessment device in one embodiment;

[0039] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0041] In one embodiment, such as Figure 1 As shown, a code cloning risk assessment method is provided, including the following steps:

[0042] Step 102: Obtain project information and clonal lineage data, and extract risky clonal features from the project information.

[0043] Risk clone characteristics include code characteristics, developer characteristics, and project characteristics. In this step, clone lineage data describes the evolutionary relationship and history between code clone pairs, recording information about a series of processes from code clone creation and modification to possible deletion.

[0044] For example, clone lineage data includes: clone instance identifiers, timestamps, version information, modification operation records, and clone relationships. The clone instance identifier assigns a unique identifier to each cloned code snippet; for example, clone code snippet A might be identified as CloneID_1001. The timestamp records the time of key events such as clone creation and modification. For example, if a cloned code snippet was first detected on March 1, 2024, this time would be recorded in the timestamp. Version information is associated with the software version where the code clone resides. For instance, if software is updated from version 1.0 to version 2.0, the clone's version information would show the differences and changes between the two versions. Modification operation records detail the modifications made to the cloned code, such as adding new features, fixing vulnerabilities, and optimizing performance. For example, "A new verification function was added to clone code snippet B to improve security." Clone relationships describe the relationships between different cloned code snippets, including whether they were cloned from the same original code or whether one clone is a derivative version of another. For example, clone code snippet C is obtained by partially modifying clone code snippet D; this relationship would be recorded.

[0045] In this step, project information and clone lineage data can be obtained through automatic extraction by tools or based on code analysis techniques. Tools such as ECC and FCG can automatically identify and analyze cloned code in the codebase and generate corresponding lineage data. Alternatively, version control systems like Git can be used. By comparing different versions of code files, the code change history and similar parts can be identified, thus inferring code clones and their evolutionary relationships. For example, Git's logging feature can be used to view detailed information for each commit, including modified files, added or deleted lines of code, thereby analyzing the generation and changes of code clones. No further specific restrictions are imposed.

[0046] Step 104: Construct a cloning risk assessment framework.

[0047] The clone risk assessment framework includes: modification frequency metrics, modification percentage metrics, modification submission time interval metrics, and consistency modification delay metrics.

[0048] In this embodiment, the modification count metric refers to the ratio of the number of modifications made by a clone instance to the total number of clone instances, used to describe the number of modifications made by a clone after its creation. The modification percentage metric refers to the proportion of consistent modifications to the total modifications during clone evolution, used to describe the number of consistent changes that occur. The modification commit time interval metric refers to the average time interval between all commit actions between two consistent changes, used to describe the latency between consistent changes. The consistent modification latency metric refers to the existence of two different commit events that change the same type of code (e.g., both adding code, both deleting code, both modifying code) and the same content (e.g., adding the same code content after modification).

[0049] Step 106: Using a cloning risk assessment framework, the cloning risk level of each code clone pair is assessed based on project information and cloning lineage data.

[0050] Step 108: Train a pre-built XGBoost model based on the cloning risk level and risk cloning characteristics so that the XGBoost model can evaluate the code cloning risk level.

[0051] The aforementioned code cloning risk assessment method first acquires project information and clone lineage data, extracting risky cloning features from the project information. Then, based on the relationship between code modification and code cloning risk, a cloning risk assessment framework is constructed to assess the project's risk. This method eliminates the need for risk events to occur and relies on developer experience. The project is then assessed using this framework, and an XGBoost model is trained based on the assessed risk level and extracted risky cloning features. This model is then capable of evaluating the code cloning risk level.

[0052] In one embodiment, the method for obtaining project information and clone lineage data includes: setting multiple star count ranges from GitHub based on the number of stars; randomly crawling open-source Java projects within each star count range, and extracting clone lineage data at the function granularity using a clone lineage extraction tool to obtain project information and clone lineage data; and storing the project information and clone lineage data in a database.

[0053] In this embodiment, the "stars" count represents the number of times other developers have followed and liked a project. Crawling projects with different star counts can improve the generalization of project selection. For example, open-source Java projects can be randomly crawled from four ranges: 0-10, 11-100, 101-1000, and greater than 1000 stars. Figure 2 As shown, all the acquired project information and cloning lineages are stored in the database. Subsequently, based on the collected data, risk cloning-related factor data are acquired and cloning risk levels are classified.

[0054] In one embodiment, the code features include: whether the function names of the code clone pairs are the same, whether the code snippets of the code clone pairs are exactly the same, whether one of the two code snippets in the code clone pair is a functional code snippet and the other is a test code snippet, the number of line history changes of the clone code pair, and the number of code snippets in the submitted code that are clones of each other.

[0055] Specifically, when code functions in a clone pair have the same name, they tend to achieve the same goal. This necessitates simultaneous modification during subsequent code changes; otherwise, it carries risks. Therefore, the identical function names in code clone pairs are chosen as a code characteristic.

[0056] Identical code can be considered duplicate code. Subsequent modifications are more likely to require simultaneous changes, potentially leading to risks due to inconsistent modifications. Therefore, the identicality of code snippets between code clones is chosen as a key characteristic.

[0057] If the two code snippets in a clone pair represent a function and its corresponding test function, any subsequent changes to the function will also require modification of the test function. However, since the function and test functions are located in different places, it's easy to forget to modify them simultaneously, posing a significant risk. Therefore, determining whether one code snippet in the clone pair is a function snippet and the other a test snippet is chosen as a code characteristic.

[0058] Code that has undergone frequent changes in its history is considered risky, as frequent changes are more likely to lead to forgetting that corresponding cloned code snippets need to be modified simultaneously. Therefore, the number of historical changes to a specific line of code in cloned code is chosen as a code characteristic.

[0059] The more code snippets submitted that are clones of each other, the greater the potential for risk, as it's easier to forget to modify one of the code snippets. Therefore, the number of mutually cloned code snippets is chosen as a code characteristic.

[0060] In another embodiment, developer characteristics include: information on the code submitter's project experience, whether the code submitters of cloned code snippets are the same, and the number of historical collaborating developers of the cloned code snippets.

[0061] Specifically, selecting code submitters' project experience as a developer characteristic is as follows: experienced core developers who have restructured projects are more familiar with the project and the cloning situation, making them more likely to synchronize the changes to cloned code snippets during future modifications. However, inexperienced developers may not be able to clearly understand the code cloning situation, and are less likely to be able to synchronize the changes to cloned code during subsequent modifications, potentially leading to risks.

[0062] The choice of whether the code committers of mutually cloned code snippets are the same is a developer characteristic: developers tend to reuse existing code for software development. If the code snippets are committed by the same person, the committer understands the code logic they developed in the past, and the possibility of introducing risks during reuse is lower.

[0063] The number of historical collaborating developers selected as a developer characteristic for cloning code snippets is as follows: the more collaborating developers there are, the less communication they have among themselves, and the greater the risk of subsequent problems arising from the resulting code clones.

[0064] In one embodiment, the project characteristics include: the project in which the code clone pair resides. The code cloning situation varies across different projects, and different project teams have different methods for introducing and processing cloned code; therefore, it is necessary to distinguish between clone pairs from different projects.

[0065] In one embodiment, the risk level is 0 when the number of modifications is 0 or the number of modifications is greater than 0 and the proportion of modifications is equal to 0; the risk level is 1 when the number of modifications and the proportion of modifications are greater than 0 and the time interval between modification and submission is equal to 0; the risk level is 2 when the number of modifications, the proportion of modifications, and the time interval between submissions are all greater than 0 and the consistent modification delay is equal to 0; and the risk level is 3 when the number of modifications, the proportion of modifications, the time interval between submissions, and the consistent modification delay are all greater than 0.

[0066] Specifically, such as Figure 3As shown, CPI (Changes per clone Instance, the ratio of the number of modifications to a clone instance to the number of clone instances) describes the number of modifications a clone has undergone since its creation. When CPI = 0, the clone code has not undergone any changes, and therefore poses no harm; the risk level is recorded as 0. CCR (Consistent Change Ratio, the proportion of consistent modifications to total modifications during clone evolution) describes the number of consistent changes that occur. To adapt to the software environment, developers inevitably modify clones. However, even if bug fixes occur, as long as no consistent changes occur (i.e., CCR = 0), it means that the bug fix was not caused by the creation of the clone fragment, so the clone is considered harmless, and the risk level is recorded as 0. CCL (Consistent Change Latency, the average time interval between all commit actions between two consistent changes) describes the latency between consistent changes. If consistent changes are always completed in the same commit (i.e., CCL = 0), it indicates that there is significant evolutionary coupling between clones, and when changes occur, it is necessary to maintain the consistency of the clone pair or the clone class as a whole, resulting in high maintenance costs. Although there is a risk of inconsistency defects, since no software errors have yet occurred, the cloned code at this stage poses only a low risk, denoted as risk level 1. The cloned fragment is then assessed for any code commits that address bug fixes related to LCC (Late Consistent Changes). LCC refers to two distinct commit events with the same type of change (e.g., both adding, deleting, or modifying code) and identical content (e.g., adding the same code after modification). If bug fixes exist in the LCC commits, it indicates that the cloned fragment has already experienced software errors due to inconsistent behavior during the period when code commit changes were not unified. The clone may still experience inconsistencies in the future, posing a high risk to the software, denoted as risk level 3. If no bug fixes exist, it means that the inconsistent clone pair has not yet caused software errors, but the risk of future errors cannot be ruled out, denoted as risk level 2. Following this method, the risk level of all clone pairs is assessed using a range of 0-3. The risk levels for all clone pairs are then obtained and stored in the database along with the clone lineage data.

[0067] In one embodiment, the risk cloning feature is used as the independent variable and the cloning risk level is used as the dependent variable to train a multi-class XGBoost model.

[0068] Specifically, the range and form of each value of the risk clone-related factors obtained during the data acquisition phase are different. To ensure the effectiveness of subsequent model training and mitigate the impact of factor bias, data preprocessing is necessary. For continuous variables, a "+1" operation followed by log transformation is performed, and then the data is standardized to a comparable dimension (mean of 0, variance of 1). For discrete variables, the original characteristics of the variables are preserved. The processed related factors constitute the feature vector of the clone code pairs, serving as the independent variables of the dataset; the risk level of the clone pairs serves as the target variable (dependent variable) of the dataset. The dataset is randomly divided into training, validation, and test sets in an 8:1:1 ratio for subsequent model training and evaluation.

[0069] In addition, an XGBoost model was selected to train a multi-classifier capable of predicting the risk of cloned code pairs. The input of the classifier is the risk-related factors of the cloned code pairs, and the output is the risk rating of the cloned code pairs in the range of 0-3. There are two main reasons for choosing XGBoost: (1) Efficiency: XGBoost adopts parallel processing and caching optimization techniques during training, which enables it to maintain a relatively fast speed when processing large-scale datasets and can adapt to the large-scale historical development data of open source projects; (2) Multi-class support: XGBoost natively supports multi-class problems without additional modification or settings, and can automatically process multi-class labels, meeting the four-class classification requirement of the 0-3 level in the risk rating of cloned code in this invention. The XGBoost model was trained using the training set data obtained after preprocessing, and the performance of the model was evaluated using the test set data. Based on the performance of the model on the test set, the XGBoost parameters were adjusted to optimize the model performance. The performance of the model was further verified using the validation set to ensure that the model performs well on different data subsets, and finally a tool for predicting the risk level of cloned code when it is submitted was obtained.

[0070] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0071] In one embodiment, such as Figure 4As shown, a code cloning risk assessment device is provided, including: a data acquisition module 402, an assessment framework construction module 404, a risk assessment module 406, and a training module 408, wherein:

[0072] The data acquisition module 402 is used to acquire project information and clone lineage data, and extract risk clone features from the project information; the risk clone features include: code features, developer features and project features.

[0073] The assessment framework construction module 404 is used to construct a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistent modification delay index.

[0074] The risk assessment module 406 is used to assess the cloning risk level of each code clone pair based on the project information and cloning lineage data using the cloning risk assessment framework.

[0075] Training module 408 is used to train a pre-built XGBoost model based on the cloning risk level and risk cloning characteristics, so that the XGBoost model can evaluate the code cloning risk level.

[0076] In one embodiment, the data acquisition module 402 is used to set multiple star count ranges from GitHub according to the number of stars; randomly crawl open source Java projects in each star count range, and extract the clone lineage at the function granularity using a clone lineage extraction tool to obtain project information and clone lineage data; and store the project information and clone lineage data in a database.

[0077] In one embodiment, the code features include: whether the function names of the code clone pairs are the same, whether the code snippets of the code clone pairs are exactly the same, whether one of the two code snippets in the code clone pair is a functional code snippet and the other is a test code snippet, the number of historical changes to the corresponding line of the clone code pair, and the number of code snippets in the submitted code that are clones of each other.

[0078] In one embodiment, the developer characteristics include: information on the code submitter's project participation experience, whether the code submitters of the cloned code snippets are the same, and the number of historical collaborating developers of the cloned code snippets.

[0079] In one embodiment, the project features include: code clones of the project.

[0080] In one embodiment, the evaluation framework construction module 404 is further configured to: assign a risk level of 0 when the number of modifications is 0 or the number of modifications is greater than 0 and the proportion of modifications is equal to 0; assign a risk level of 1 when the number of modifications and the proportion of modifications are greater than 0 and the time interval between modifications and submissions is equal to 0; assign a risk level of 2 when the number of modifications, the proportion of modifications, and the time interval between submissions are all greater than 0 and the consistent modification delay is equal to 0; and assign a risk level of 3 when the number of modifications, the proportion of modifications, the time interval between submissions, and the consistent modification delay are all greater than 0.

[0081] In one embodiment, the training module 408 is further configured to train a multi-class XGBoost model using the risk clone feature as an independent variable and the clone risk level as a dependent variable.

[0082] Specific limitations regarding the code cloning risk assessment device can be found in the limitations of the code cloning risk assessment method described above, and will not be repeated here. Each module in the aforementioned code cloning risk assessment device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0083] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a code cloning risk assessment method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0084] Those skilled in the art will understand that Figure 5The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0085] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0086] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0087] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0088] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0089] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for assessing the risk of code cloning, characterized in that, The method includes: Obtain project information and clone lineage data, and extract risky clone features from the project information; the risky clone features include: code features, developer features, and project features; the clone lineage data includes: clone instance identifier, timestamp, version information, modification operation record, and clone relationship; the code features include: whether the function names of the code clone pairs are the same, whether the code snippets of the code clone pairs are completely identical, whether one of the two code snippets in the code clone pair is a functional code snippet and the other is a test code snippet, the number of historical changes to the corresponding line of the clone code pair, and the number of code snippets that are clones of each other in the submitted code; Construct a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistency modification delay index; Using the aforementioned cloning risk assessment framework, the cloning risk level of each code clone pair is assessed based on the project information and cloning lineage data. Based on the cloning risk level and risk cloning characteristics, a pre-built XGBoost model is trained so that the XGBoost model can evaluate the code cloning risk level. The framework for cloning risk assessment includes: When the number of modifications is 0, or when the number of modifications is greater than 0 and the percentage of modifications is equal to 0, the risk level is 0. When the number of modifications and the percentage of modifications are both greater than 0, and the time interval between modification submissions is equal to 0, the risk level is 1. When the number of modifications, the percentage of modifications, and the time interval between submissions are all greater than 0, and the consistency modification delay is equal to 0, the risk level is 2. When the number of modifications, the percentage of modifications, the time interval between submissions, and the delay in consistent modifications are all greater than 0, the risk level is 3.

2. The method according to claim 1, characterized in that, The acquisition of project information and cloning lineage data includes: Set multiple star count ranges from GitHub based on the number of stars; Open-source Java projects are randomly crawled within each star count range, and clone lineage extraction tools are used to extract clone lineages at the function granularity to obtain project information and clone lineage data. The project information and clonal lineage data are stored in the database.

3. The method according to claim 1, characterized in that, The developer characteristics include: information on the code submitter's project participation experience, whether the code submitters of cloned code snippets are the same, and the number of historical collaborating developers for cloned code snippets.

4. The method according to claim 1, characterized in that, The project features include: code clones of the project.

5. The method according to any one of claims 1 to 4, characterized in that, Based on the cloning risk level and risk cloning characteristics, a pre-built XGBoost model is trained, including: Using the risk cloning features as independent variables and the cloning risk level as the dependent variable, a multi-class XGBoost model is trained.

6. A code cloning risk assessment device, characterized in that, The apparatus for performing the code cloning risk assessment method according to any one of claims 1 to 5, the apparatus comprising: The data acquisition module is used to acquire project information and clone lineage data, and extract risk clone features from the project information; the risk clone features include: code features, developer features, and project features. The assessment framework construction module is used to build a clone risk assessment framework; the clone risk assessment framework includes: modification frequency index, modification percentage index, modification submission time interval index, and consistent modification delay index. The risk assessment module is used to assess the cloning risk level of each code clone pair based on the project information and cloning lineage data using the cloning risk assessment framework. The training module is used to train a pre-built XGBoost model based on the cloning risk level and risky cloning characteristics, so that the XGBoost model can evaluate the code cloning risk level.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images