Operable code peculiar smell recognition method and system based on supervised comparative learning

Abstract

The invention discloses an operable code peculiar smell recognition method and system based on supervised comparative learning. According to the method, the life cycle of the code peculiar smell is generated by means of a Violation Tracker tool, and multi-dimensional features of code defects are advanced, including row-level codes, method-level codes, file names and peculiar smell types. The method comprises the following steps: firstly, preprocessing data, and labeling the data according to the life cycle of code odor; then, a strategy of supervised comparative learning is used for performing fine adjustment on the pre-training model, early-stage model parameters are frozen after fine adjustment, and a classification layer network is trained independently; and finally, the whole trained network model is utilized to carry out operable code peculiar smell recognition. The method has the advantages of being high in precision and efficiency, small in influence on the data scale and the like, and operable code defects can be effectively recognized. And the pre-training model is finely adjusted by innovatively adopting supervised comparative learning, so that the accuracy of identifying the odor of the operable code is remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of code odor identification, and specifically to an operable code odor identification method and system based on supervised contrastive learning. Background Technology

[0002] As the scale and complexity of software systems continue to increase, code quality has become a core concern in the field of software engineering. Automated static analysis tools, which can identify potential problems by statically examining source code or intermediate code, have gained widespread application in recent years. A significant advantage of automated static analysis tools is their ability to effectively identify potential problems in code without executing the program. This allows development teams to discover and resolve issues early in the software development lifecycle, thereby significantly improving code robustness and maintainability. Currently, automated static analysis tools are deeply integrated into modern software development practices and are widely integrated into various stages such as continuous integration processes, integrated development environments, and code review tools.

[0003] However, despite the significant theoretical value of automated static analysis tools, their practical application faces multiple challenges. The primary issues are high false positive rates and information overload. First, a high false positive rate not only increases the cognitive burden on developers but may also lead to distrust of the tool, thus reducing its actual usage. Second, the timeliness of violation remediation is also a concern; a considerable proportion of violations are shelved or delayed during development, exacerbating information overload and potentially threatening software quality. Furthermore, the complexity of warning classification significantly impacts development efficiency. Developers often spend considerable time prioritizing warnings because they believe some warnings have no substantial impact on program functionality. This time-consuming filtering process not only reduces development efficiency but may also cause truly critical violations to be overlooked, thereby weakening the practical effectiveness of automated static analysis tools.

[0004] To improve the practicality of automated static analysis tools, the research community has begun to focus on the identification of "actionable violations." Actionable violations refer to those violation warnings that genuinely require developer attention and remediation. Early research primarily relied on manually designed features (such as code complexity, variable usage frequency, and code modification history) for violation warning classification. However, this approach is overly dependent on feature selection and struggles to adapt to complex and ever-changing code scenarios. With the development of machine learning techniques, researchers have begun to train classification models using large-scale codebases to automatically identify actionable violations through a data-driven approach. In particular, the introduction of project context features (such as developer experience and code commit history) has further improved the accuracy and applicability of the models. In recent years, the introduction of deep learning technology has injected new vitality into this field. For example, learning code semantic features through deep neural networks (such as CodeBERT) has not only significantly improved the performance of warning classification but also greatly reduced the reliance on manual feature engineering. Furthermore, some studies have begun to delve into the remediation behavior patterns of developers, exploring the key factors influencing developers' remediation decisions, providing important empirical evidence for optimizing ASAT tool configurations.

[0005] However, existing research still has the following limitations: Insufficient contextual information: Existing research lacks analysis of complete contextual information regarding the generation and remediation of warnings, making it difficult to deeply understand the root causes of warnings and their remediation patterns. Limitations of feature capture: Traditional feature engineering methods rely on manually designed features, making it difficult to fully capture the semantic information of the program. While deep learning methods can automatically learn features, they often focus on the surface-level syntactic features of the code, neglecting structured information such as the program's control flow and data flow. Lack of validation in cross-project scenarios: Most studies only evaluate within a single project, lacking validation of effectiveness in cross-project scenarios, limiting the generality and applicability of the technology. Insufficient modeling of developer behavior: Existing research still has a relatively preliminary modeling of developer behavior and team collaboration, failing to fully consider the knowledge differences and collaboration patterns among developers. Insufficient in-depth analysis of violation types: Research rarely comprehensively understands remediation behavior from the perspective of violation types, failing to reveal the remediation priorities and decision-making logic of different types of violations. Summary of the Invention

[0006] To overcome the shortcomings of the existing technology, this invention proposes a method and system for identifying operational code odors based on supervised contrastive learning. This invention uses a supervised contrastive learning strategy to fine-tune a pre-trained model, aiming to improve the application effect of the pre-trained model in operational warning identification.

[0007] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows:

[0008] In a first aspect, the present invention provides an operational code odor identification method based on supervised contrastive learning, which includes the following steps:

[0009] S1: Construct a code smell dataset based on projects on the code hosting service platform. For each code smell instance, extract the line-level code, method-level code, file name, and smell type as multi-dimensional features. At the same time, label whether the code smell instance belongs to the actionable code smell based on the life cycle of the code smell instance.

[0010] S2: Input the line-level code of each code smell instance in the code smell dataset into the pre-trained model, and extract the hidden vector of the last layer of the model as the semantic representation of the code smell instance. Then, calculate the mean vector of the semantic representation of all code smell instances under each smell type to obtain the feature vector of that smell type. Finally, use the K-means clustering algorithm to cluster the feature vectors of all smell types and divide all smell types into multiple clusters.

[0011] S3: For each cluster, perform intra-class label distribution balancing on all code smell instances under the smell type contained in the cluster, and then divide them into multiple mini batches; encode the multi-dimensional features of the code smell instances in each mini batch into sentence embeddings and input them into the backbone neural network composed of a pre-trained model and a bidirectional long short-term memory (Bi-LSTM) model, and use a supervised contrastive learning strategy to perform distributed training on the backbone neural network;

[0012] S4: After training is completed, the parameters of the backbone neural network are frozen and a classification layer network is connected to form an operable code odor recognition network. The classification layer network is trained under supervision using the code odor dataset, and the operable code odor recognition network is used to identify operable code odors.

[0013] As a preferred embodiment of the first aspect above, in step S1, a series of Java projects are cloned from the code hosting service platform to the local repository, and the ViolationTracker tool is used to identify and extract the complete lifecycle of each code smell instance from different revisions of the Java projects. At the same time, the specific code of the line containing the code smell is extracted from the identification results of the ViolationTracker tool as the line-level code, the full path of the file containing the code smell is extracted as the file name, the specific quality problem category of the code smell is extracted as the smell type, and then the complete implementation of the method containing the code smell is extracted from the local repository as the method-level code based on the line number and method name of the method containing the code smell.

[0014] As a preferred embodiment of the first aspect above, the method for generating tags for the code odor instance is as follows:

[0015] Based on the lifecycle of the current code smell instance and all revision information of the project in which the code resides, determine whether the current code smell instance has been fixed in the project or whether it has disappeared due to file deletion. If the current code smell instance has been fixed in the project, it is tagged as an operable code smell. If the current code smell instance has not been fixed in the project or has disappeared due to file deletion, it is tagged as an inoperable code smell.

[0016] As a preferred embodiment of the first aspect above, in S2, when using the K-means algorithm for clustering, the Euclidean distance between feature vectors of different odor types is used as a similarity metric, and the optimal clustering result is selected through multiple random initializations.

[0017] As a preferred embodiment of the first aspect above, in step S3, the method for performing intra-class label distribution balancing processing and constructing a mini-batch for each cluster is as follows:

[0018] Take all code smell instances under all smell types in the current cluster as the initial sample set, and then count the number of operable code smell tags and inoperable code smell tags contained in the initial sample set;

[0019] If there is only one label in the initial sample set, then all samples are discarded and the current cluster is skipped to process the next cluster.

[0020] If the initial sample set contains both labels, the first ratio is calculated by dividing the total number of samples in the initial sample set by the total batch size. Simultaneously, the second ratio is calculated by dividing the number of samples corresponding to the more common label in the initial sample set by the difference between the total batch size and the number of GPUs used for distributed training of the model. An oversampling strategy is used to expand the initial sample set by clustering samples with fewer labels, increasing the total number of samples in the expanded sample set to the larger of the first and second ratios. Then, the samples in the expanded sample set are randomly shuffled and uniformly distributed to mini-batches corresponding to the GPUs used for distributed training of the model. The number of samples allocated to each mini-batch is the ratio of the total batch size to the number of GPUs used for distributed training of the model.

[0021] As a preferred embodiment of the first aspect mentioned above, the pre-trained model employs CodeBERT, and when using a supervised contrastive learning strategy to perform distributed training on the backbone neural network, different dropout rates are set to achieve data augmentation.

[0022] As a preferred embodiment of the first aspect above, in S4, the classification layer network is a linear layer with a Softmax activation function, and the loss function used to train the classification layer network is the cross-entropy loss function.

[0023] In a second aspect, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, can implement the operable code odor identification method based on supervised contrastive learning as described in any of the first aspects above.

[0024] Thirdly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the implementation of the supervised contrastive learning-based operational code odor identification method as described in any of the first aspects above.

[0025] Fourthly, the present invention provides a computer electronic device, which includes a memory and a processor;

[0026] The memory is used to store computer programs;

[0027] The processor is configured to, when executing the computer program, implement the operable code odor identification method based on supervised contrastive learning as described in any of the first aspects above.

[0028] This invention utilizes multi-dimensional features and a supervised contrastive learning strategy to fine-tune a pre-trained model, thereby identifying operable code smells. This invention offers the following advantages:

[0029] 1. This invention utilizes the ViolationTracker tool, which can accurately match the complete lifecycle of a violation. Using this tool, a large and accurate dataset can be obtained.

[0030] 2. This invention uses context-enhanced representation of code smells, and achieves efficient representation of code smells through systematic extraction of context information and semantic-driven type clustering;

[0031] 3. This invention uses a supervised contrastive learning strategy to fine-tune the pre-trained model, enabling it to learn more discriminative features. This helps enhance the model's ability to represent data and improves its generalization ability. Attached Figure Description

[0032] Figure 1 This is a schematic diagram illustrating the steps of the operable code odor identification method based on supervised contrastive learning in an embodiment of the present invention.

[0033] Figure 2This is a flowchart of an operable code odor identification method based on supervised contrastive learning in an embodiment of the present invention.

[0034] Figure 3 This is a schematic diagram of the operable code odor recognition model structure in an embodiment of the present invention.

[0035] Figure 4 This is a block diagram of the operable code odor identification system based on supervised contrastive learning in an embodiment of the present invention.

[0036] Figure 5 This is a schematic diagram of the structure of a computer electronic device in an embodiment of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings.

[0038] Conversely, this invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of the invention as defined in the claims. Furthermore, to provide the public with a better understanding of the invention, certain specific details are described in detail below. However, those skilled in the art will fully understand the invention even without these detailed descriptions.

[0039] like Figure 1 As shown, in a preferred embodiment of the present invention, an operable code odor identification method based on supervised contrastive learning is provided, which includes the following four steps S1 to S4. The method flow is as follows: Figure 2 As shown below, the specific implementation of each step will be described in detail.

[0040] S1: Dataset Construction: Construct a code smell dataset based on projects on the code hosting service platform. For each code smell instance, extract the line-level code, method-level code, file name, and smell type as multi-dimensional features. At the same time, label whether the code smell instance belongs to the actionable code smell according to the life cycle of the code smell instance.

[0041] It should be noted that the code hosting service platform in this invention can theoretically be any code hosting service platform, such as GitHub, GitLab, Bitbucket, Gitee, etc. In the implementation of this invention, GitHub, a code hosting service platform with a large number of open source projects currently used by developers, is used. Java projects with many iterations are cloned from the platform, and code smell instances are extracted from them. The extraction of code smell instances can be achieved using the ViolationTracker tool, because the ViolationTracker tool can accurately match the complete lifecycle of violations.

[0042] In an embodiment of the present invention, the process of constructing the dataset in S1 above can be specifically implemented through the following steps S11 to S13:

[0043] S11. Clone the Java project from GitHub to your local machine and create a local GitHub repository. Then, use the ViolationTracker tool to identify and obtain the complete lifecycle of each code smell instance from different revisions of the Java project. In this invention, the complete lifecycle of a code smell instance refers to the lifecycle of a specific code smell S within a software development project. i Between different revisions, it goes through the entire process from its appearance, to being fixed, and finally disappearing. Example S of code smells. i The complete lifecycle can be traced through the commit timestamp of the revision in which the specific code smell occurred (the timestamp of the j-th revision is denoted as l). j This can be represented by, for example, the commit timestamp of the revision in which the specific code smell first appeared is l1, and the commit timestamp of the revision in which it last appeared is l. N Then its lifecycle can be represented as (l1,l2,…,l N ).

[0044] S12. Extract the multidimensional features of each code smell instance, where each code smell S i The multidimensional features included are divided into four categories:

[0045] (1) Line-level code: The specific code of the line where the code smell is located. It is used to capture the specific implementation details of the smelly code, so as to accurately locate the problematic code fragment.

[0046] (2) Method-level code: The complete implementation of the method where the code smell is located, which provides a wider range of execution environment information and helps to understand the interaction between the smelly code and the surrounding code.

[0047] (3) File name: The full path of the file where the code smell is located, which reflects the module to which the code belongs, making it easier to track similar problems in similar modules.

[0048] (4) Odor type: The specific category of quality problem, used to guide the determination of repair priorities and directions.

[0049] Method-level code features are extracted from the local repository of the GitHub project based on the line number of the code smell and the method name of the corresponding method. Other features can be obtained directly from the results of the ViolationTracker tool.

[0050] Therefore, for each code smell instance identified by the ViolationTracker tool, the specific code of the line containing the code smell can be extracted from the ViolationTracker tool's identification results as the above-mentioned line-level code features, the full path of the file containing the code smell can be extracted as the above-mentioned filename features, the specific quality problem category of the code smell can be extracted as the above-mentioned smell type features, and then, based on the line number of the code smell and the method name of the method containing the code smell, the complete implementation of the method containing the code smell can be extracted from the local repository as the above-mentioned method-level code features.

[0051] S13. Based on the lifecycle of the current code smell instance and all revision information of the project containing the code, determine whether the current code smell instance has been fixed in the project and whether it has disappeared due to file deletion. If the current code smell instance has been fixed in the project, it is labeled as an operable code smell. If the current code smell instance has not been fixed in the project or has disappeared due to file deletion, it is labeled as an inoperable code smell. In embodiments of the present invention, the final label can be determined comprehensively based on the timestamp in the lifecycle, the data collection deadline, and the file deletion status. For each code smell S i The specific steps for determining the label are as follows:

[0052] (1) Preliminary annotation: For each code smell S i Lifecycle (l1,l2,…,l) N ), with the code's odor S i The commit timestamp of the last version of the project is used as the data collection deadline. If S i At the end of the life cycle N If the timeframe is not equal to the data collection deadline for this project, it indicates a code smell (S). i If the code has been fixed or deleted before the data collection deadline, it is initially marked as having an "Aberration S". i A code smell is considered operable; otherwise, it is marked as inoperable. In this embodiment, label 0 can represent operable code smells, and label 1 can represent inoperable code smells.

[0053] (2) Eliminating code smells caused by file deletion: Further analysis of code smells initially marked as actionable by examining the commit logs of GitHub projects. i Adjust the labels; if initially labeled as an operable code smell, then... i The file in question is at the end of its lifecycle. N If deleted, the code smell S i Re-marked as inoperable code smell.

[0054] S2: Type Clustering: Input the line-level code of each code smell instance in the code smell dataset into the pre-trained model, and extract the hidden vector of the last layer of the model as the semantic representation of the code smell instance. Then, calculate the mean vector of the semantic representation of all code smell instances under each smell type to obtain the feature vector of that smell type. Finally, use the K-means clustering algorithm to cluster the feature vectors of all smell types and divide all smell types into multiple clusters.

[0055] In an embodiment of the invention, the CodeBERT pre-trained model is used. Each code smell instance S... i After inputting line-level code into the pre-trained model, the hidden state of the last layer of the pre-trained model is extracted to have a dimension of 1*768. This 1*768-dimensional hidden vector can be used as the code smell instance S. i The semantic representation of each odor type is used to cluster the feature vectors of each odor type. Each odor type contains a series of code odor instances. The semantic representations of all code odor instances of the same odor type are averaged to obtain the feature vector of that odor type, which is then used in subsequent clustering algorithms. In this embodiment, the K-means algorithm is used to cluster the feature vectors of each type, using the Euclidean distance between the feature vectors of different odor types as a similarity measure. The optimal clustering result is selected through multiple random initializations. The number of random initializations can be chosen according to actual needs. Based on a preset number of clusters K, each clustering iteration randomly selects K feature vectors of different odor types as initial cluster centers. This aims to improve the quality and stability of the clustering results and find the global optimum. Furthermore, the number of clusters K can be optimized based on the actual results.

[0056] S3: Code Smell Representation Learning: For each cluster, all code smell instances under the smell types contained in that cluster undergo intra-class label distribution balancing and are then divided into multiple mini-batches. The multi-dimensional features of the code smell instances in each mini-batch are encoded into sentence embeddings and input into the backbone neural network, which is a cascaded pre-trained model and a Bidirectional Long Short-Term Memory (Bi-LSTM) model. A supervised contrastive learning strategy is used to perform distributed training on the backbone neural network. Furthermore, in the embodiments of this invention, data augmentation can be achieved by setting different dropout rates when using the supervised contrastive learning strategy to perform distributed training on the backbone neural network.

[0057] It should be noted that, in this embodiment, a CodeBERT pre-trained model is used; therefore, the aforementioned backbone neural network adopts a CodeBERT+Bi-LSTM network structure. This backbone neural network is trained using contrastive learning. The value of the last hidden layer state output by CodeBERT is input into the Bi-LSTM to calculate the contrastive learning loss. The specific form of the contrastive learning loss function can be designed with reference to existing technologies; its purpose is to amplify the differences in output features of samples with different labels in the Bi-LSTM.

[0058] It should also be noted that the purpose of dividing the code smell instance samples corresponding to the total batch size into smaller batches in this invention is to adapt to the needs of multiple GPUs for parallel processing in distributed training.

[0059] In an embodiment of the present invention, the process of constructing a Mini Batch and performing distributed training on the backbone neural network is as follows:

[0060] S31: Constructing a Mini Batch: Perform intra-class label distribution balancing for each class cluster and construct a Mini Batch. The steps are as follows:

[0061] (1) For each cluster T i The initial sample set is formed by taking all code smell instances under all smell types belonging to the current cluster and counting the number of operable and inoperable code smell tags in the initial sample set. If cluster T i If the initial sample set contains data with only one label, then the entire cluster T... i The initial sample set is discarded, the MiniBatch construction of the current cluster is skipped, and the next cluster is processed directly. If cluster T i If the initial sample set contains data with two labels, then proceed to the next step (2).

[0062] (2) For each retained cluster T i The initial sample set is expanded using an oversampling strategy that clusters with fewer labeled samples, so that the total number of samples in the expanded sample set is N. i =max(x,y) samples, meaning the total number of samples needs to be expanded to the larger of the first ratio x and the second ratio y. The first ratio x and the second ratio y are calculated as follows:

[0063] The first ratio x is obtained by dividing the total number of samples in the initial sample set by the total batch size:

[0064]

[0065] The number of samples corresponding to the more common labels in the initial sample set is divided by the total batch size, minus the number of samples trained by the distributed training model.

[0066] The difference between the number of GPUs used (n_gpu) is used to obtain the second ratio y:

[0067]

[0068] Where label_0 and label_1 are the clusters T, respectively. i The initial sample set contains the number of data samples labeled 0 (representing operable code smells) and 1 (representing non-operable code smells). `batch_size` is the batch size hyperparameter used for model training. `n_gpu` is the number of GPUs used for distributed training.

[0069] (3) For each cluster T i After expanding the sample set, all sample data are randomly shuffled. Then, a uniform distribution strategy is used to allocate the two-label sample data from the expanded sample set to each MiniBatch, ensuring a relatively balanced distribution of sample labels within each MiniBatch. The number of samples allocated to each MiniBatch is the ratio of the total batch size to the number of GPUs n_gpu used for distributed training of the model, calculated as follows:

[0070]

[0071] S32: Backbone Neural Network Structure and Input / Output Design: The four information parts of the code smell are connected into a sequence and separated by the [SEP] marker, forming a unified input format for the backbone neural network structure as follows:

[0072] [CLS]Line-level code[SEP]Method-level code[SEP]Odor type[SEP]Filename[SEP]

[0073] In this embodiment, the maximum input length of the CodeBERT pre-trained model is specified as 512, while the vector length of line-level code is limited to 128. Then, the vector length of method-level code is determined by subtracting the vector length occupied by line-level code, flavor type, and filename from the maximum input length. Simultaneously, during supervised contrastive learning, four different dropout rates ([0.1, 0.0, 0.05, 0.2]) are used for data augmentation.

[0074] For any i-th sample in each MiniBatch, the input in the above format is encoded using sentence embedding and then fed into the CodeBERT pre-trained model. The output with the [CLS] label is extracted from the last hidden state of the CodeBERT pre-trained model as the initial representation of the code smell sample. Then, the initial representation of the code smell sample is fed into a Bi-LSTM network to obtain the output feature representation z used to calculate the loss. i In this embodiment, the hidden layer dimension of Bi-LSTM is set to 256.

[0075] S33: Loss Function: This invention uses... The specific formula for the supervised contrastive learning loss function is as follows:

[0076]

[0077] Where z i Let P(i) represent the feature representation of the i-th sample. P(i) represents the set of positive samples belonging to the same class as sample i. A(i) represents the set of all samples in the Mini Batch except sample i. sim() is a function used to measure the similarity between feature vectors; in this embodiment, cosine similarity is used. τ is a temperature coefficient, set to 0.07 in this embodiment. |P(i)| is the number of positive samples.

[0078] S4: Operable Code Odor Detection: After training the backbone neural network, freeze the parameters of CodeBERT and Bi-LSTM in the backbone neural network, and connect a classification layer network after the backbone neural network to form a structure as follows: Figure 3 The operational code odor identification network is shown. Using the aforementioned code odor dataset, a separate classification layer network is trained. The backbone neural network trained in S3 and the separately trained classification layer network in this step are used to construct the final operational code odor identification network that actually performs the identification task, used for operational code odor identification of target code odors. In this embodiment, the classification layer network is a linear layer with a Softmax activation function. This classification task is a binary classification task, and the loss function used during training is the cross-entropy loss function, calculated from the predicted label and the actual label.

[0079] The prediction method of this invention utilizes static code analysis technology to obtain multi-dimensional features of the performance micro-benchmark code, including code sequence, syntax structure, and control flow. It then performs feature learning through a multimodal model to predict the micro-benchmark runtime. This prediction method is characterized by high accuracy and efficiency, effectively predicting the runtime of the micro-benchmark before execution and promptly informing testers to implement appropriate performance testing strategies. Unlike existing performance testing methods that only perform post-event analysis of micro-benchmark execution results, the micro-benchmark runtime prediction method proposed in this invention is suitable for static detection of performance anomalies and offers better timeliness.

[0080] It should be noted that the method steps S1 to S4 described above can essentially be implemented in the form of computer programs and functional modules.

[0081] Therefore, based on the same inventive concept, this invention also provides a supervised contrastive learning-based operational code odor identification system, corresponding to the supervised contrastive learning-based operational code odor identification method provided in the above embodiments, for implementing the aforementioned supervised contrastive learning-based operational code odor identification method, such as... Figure 4 As shown, its functional modules include:

[0082] The dataset construction module is used to build a code smell dataset based on projects on the code hosting service platform. Each code smell instance needs to extract the line-level code, method-level code, file name, and smell type as multi-dimensional features. At the same time, the life cycle of the code smell instance is used to label whether the code smell instance belongs to the actionable code smell.

[0083] The clustering module is used to input the line-level code of each code smell instance in the code smell dataset into the pre-trained model, and extract the hidden vector of the last layer of the model as the semantic representation of the code smell instance. Then, it calculates the mean vector of the semantic representation of all code smell instances under each smell type to obtain the feature vector of that smell type. Finally, the K-means clustering algorithm is used to cluster the feature vectors of all smell types, dividing all smell types into multiple clusters.

[0084] The first training module is used to perform intra-class label distribution balancing on all code smell instances under the smell type contained in each cluster, and then divide them into multiple mini batches. The multi-dimensional features of the code smell instances in each mini batch are encoded into sentence embeddings and then input into the backbone neural network composed of a pre-trained model and a bidirectional long short-term memory (Bi-LSTM) model. The backbone neural network is then trained in a distributed manner using a supervised contrastive learning strategy.

[0085] The second training module is used to freeze the parameters of the backbone neural network after training and connect it to a classification layer network to form an operable code odor recognition network. The classification layer network is trained under supervision using the code odor dataset, and the trained operable code odor recognition network is used to identify operable code odors.

[0086] Similarly, based on the same inventive concept, this invention also provides a computer electronic device corresponding to the supervised contrastive learning-based operable code odor identification method provided in the above embodiments, such as... Figure 5 As shown, it includes a memory and a processor;

[0087] The memory is used to store computer programs;

[0088] The processor is configured to implement the operational code odor identification method based on supervised contrastive learning as described above when executing the computer program;

[0089] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0090] Therefore, based on the same inventive concept, the present invention provides a computer-readable storage medium corresponding to the operable code odor identification method based on supervised contrastive learning. The storage medium stores a computer program, which, when executed by a processor, can realize the operable code odor identification method based on supervised contrastive learning as described above.

[0091] Specifically, in the computer-readable storage medium of the above two embodiments, the stored computer program is executed by a processor, which can perform the aforementioned steps S1 to S4.

[0092] It is understood that the aforementioned storage media may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Furthermore, the storage media may also be various media capable of storing program code, such as USB flash drives, external hard drives, magnetic disks, or optical discs.

[0093] It is understood that the processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0094] It should also be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the embodiments provided in this application, the division of steps or modules in the system and method is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules or steps may be combined or integrated together, and a module or step may also be split.

[0095] The operational code odor identification method based on supervised contrastive learning shown in S1 to S4 of the above embodiments will be applied to a specific example to demonstrate its technical effect.

[0096] Example

[0097] In this embodiment, the steps of the operable code odor identification method based on supervised contrastive learning are the same as those described in S1 to S4 above, and the specific process and parameter definitions can also be found above. The specific implementation process in the example is shown below in detail:

[0098] This example selects 10 Java-heavy projects on GitHub to extract code smell examples. These projects were chosen because of their size, age (they have source code histories spanning many years), popularity (they have many stars), and the fact that they come from different fields.

[0099] Table 1. Description of Data Sources

[0100]

[0101] Table 1 presents an overview of the dataset. In Table 1, the first column is the project name, the second column is the project domain, the third column is the number of stars for the project, the fourth column is the project branch, the fifth column is the start time of project data collection, the sixth column is the end time of project data collection, the seventh column is the number of revisions for the project, the eighth column is the percentage of Java language used in the project, the ninth column is the number of code smells, the tenth column is the number of code smell types, the eleventh column is the number of actionable code smells, and the twelfth column is the percentage of actionable code smells. Ultimately, a total of 173,588 violations were collected, involving 193 types of code smells. Furthermore, this embodiment also selected the first four projects in Table 1 as a small dataset to compare the impact of data volume on the method of this invention.

[0102] To comprehensively evaluate the performance of the proposed method, commonly used evaluation metrics are employed in the embodiments of this invention. Four basic classification cases are defined: True Positive (TP) indicates that an operable violation is correctly predicted as operable; False Positive (FP) indicates that an inoperable violation is incorrectly predicted as operable; False Negative (FN) indicates that an operable violation is incorrectly predicted as inoperable; and True Negative (TN) indicates that an inoperable violation is correctly predicted as inoperable.

[0103] Based on the above definitions, the following five widely used evaluation metrics are adopted in the embodiments of the present invention:

[0104] (1) Measuring the proportion of violations predicted to be actionable is particularly useful in scenarios where assessing the cost of reviewing false positives is high.

[0105] (2) Measuring the proportion of successfully identified actionable violations out of all actual actionable violations is particularly important in scenarios where underreporting is not permissible.

[0106] (3) The evaluation model is used to assess the proportion of correct classifications across all samples, and is suitable for datasets with balanced class distributions.

[0107] (4) As the harmonic mean of precision and recall, it provides a comprehensive evaluation of the overall performance of the model.

[0108] (5) AUC (Area Under the ROC Curve): Evaluates model performance at all possible classification thresholds, especially suitable for handling imbalanced datasets.

[0109] This embodiment uses three baselines as comparison algorithms to demonstrate the effectiveness of the proposed method. The experimental results are shown in Tables 2 and 3, demonstrating that the proposed method can more accurately identify actionable code smells.

[0110] Table 2 Comparison of methods on the complete dataset

[0111]

[0112] Table 3 Comparison of methods on small datasets

[0113]

[0114] Furthermore, to verify the impact of each component of the proposed method on the prediction results, an ablation experiment was conducted in this embodiment to analyze the influence of different components on the model, thereby demonstrating the effectiveness of the method of the present invention. The experimental results are shown in Tables 3 and 4.

[0115] Table 3 Ablation experiments on the complete dataset

[0116]

[0117] Table 4 Ablation experiments on small datasets

[0118]

[0119]

[0120] The experiments in the above ablation experiments are represented as follows:

[0121] (1) Baseline model Co: The baseline model based on CodeBERT.

[0122] (2) Feature fusion mechanism Co+Fea: Based on Co, add a splicing feature fusion of code features and type and path information.

[0123] (3) Contextual understanding enhancement Co+Fea(e)+Ls: Based on Co+Fea, sentence embedding is used and Bi-LSTM is introduced to better understand the context.

[0124] (4) Contrastive learning strategy Co+Fea(e)+Ls+Sup+M(original Type): Based on Co+Fea(e)+Ls, implement mini-batch training based on the original class (without type clustering).

[0125] (5) Clustering strategy Co+Fea(e)+Ls+Sup+M(20): Based on Co+Fea(e)+Ls, small-batch training based on type clustering is implemented, which corresponds to the complete method of this invention.

[0126] On both datasets, introducing multidimensional features significantly improved performance. However, on small datasets, due to the large number of categories and the highly imbalanced number of samples within each category, coupled with significant differences between samples in each class, feature embedding leads to learning between samples with large differences. This hinders the effectiveness of supervised contrastive learning and may even negatively impact training results. In contrast, large datasets have a richer sample pool, minimizing the negative impact. Regardless of the data size, using all components enhances the final training performance of the model.

[0127] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A method for identifying operational code odors based on supervised contrastive learning, characterized in that, Includes the following steps: S1: Construct a code smell dataset based on projects on the code hosting service platform. For each code smell instance, extract the line-level code, method-level code, file name, and smell type as multi-dimensional features. At the same time, label whether the code smell instance belongs to the actionable code smell based on the life cycle of the code smell instance. S2: Input the line-level code of each code smell instance in the code smell dataset into the pre-trained model, and extract the hidden vector of the last layer of the model as the semantic representation of the code smell instance. Then, calculate the mean vector of the semantic representation of all code smell instances under each smell type to obtain the feature vector of that smell type. Finally, use the K-means clustering algorithm to cluster the feature vectors of all smell types and divide all smell types into multiple clusters. S3: For each cluster, perform intra-class label distribution balancing on all code smell instances under the smell type contained in the cluster, and then divide them into multiple mini batches; encode the multi-dimensional features of the code smell instances in each mini batch into sentence embeddings and input them into the backbone neural network composed of a pre-trained model and a bidirectional long short-term memory (Bi-LSTM) model, and use a supervised contrastive learning strategy to perform distributed training on the backbone neural network; S4: After training is completed, the parameters of the backbone neural network are frozen and a classification layer network is connected to form an operable code odor recognition network. The classification layer network is trained under supervision using the code odor dataset, and the operable code odor recognition network is used to identify operable code odors.

2. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, In step S1, a series of Java projects are cloned from the code hosting service platform to the local repository. The ViolationTracker tool is used to identify and extract the complete lifecycle of each code smell instance from different revisions of the Java projects. At the same time, the specific code of the line containing the code smell is extracted from the identification results of the ViolationTracker tool as the line-level code, the full path of the file containing the code smell is extracted as the file name, and the specific quality problem category of the code smell is extracted as the smell type. Then, based on the line number and method name of the method containing the code smell, the complete implementation of the method containing the code smell is extracted from the local repository as the method-level code.

3. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, The method for generating the label for the code odor instance is as follows: Based on the lifecycle of the current code smell instance and all revision information of the project in which the code resides, determine whether the current code smell instance has been fixed in the project or whether it has disappeared due to file deletion. If the current code smell instance has been fixed in the project, it is tagged as an operable code smell. If the current code smell instance has not been fixed in the project or has disappeared due to file deletion, it is tagged as an inoperable code smell.

4. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, In S2, when using the K-means algorithm for clustering, the Euclidean distance between feature vectors of different odor types is used as a similarity measure, and the optimal clustering result is selected through multiple random initializations.

5. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, In S3, the method for performing intra-class label distribution balancing processing and constructing a mini batch for each cluster is as follows: Take all code smell instances under all smell types in the current cluster as the initial sample set, and then count the number of operable code smell tags and inoperable code smell tags contained in the initial sample set; If there is only one label in the initial sample set, then all samples are discarded and the current cluster is skipped to process the next cluster. If the initial sample set contains both labels, the first ratio is calculated by dividing the total number of samples in the initial sample set by the total batch size. Simultaneously, the second ratio is calculated by dividing the number of samples corresponding to the more common label in the initial sample set by the difference between the total batch size and the number of GPUs used for distributed training of the model. An oversampling strategy is used to expand the initial sample set by clustering samples with fewer labels, increasing the total number of samples in the expanded sample set to the larger of the first and second ratios. Then, the samples in the expanded sample set are randomly shuffled and uniformly distributed to mini-batches corresponding to the GPUs used for distributed training of the model. The number of samples allocated to each mini-batch is the ratio of the total batch size to the number of GPUs used for distributed training of the model.

6. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, The pre-trained model uses CodeBERT, and when the backbone neural network is trained in a distributed manner using a supervised contrastive learning strategy, different dropout rates are set to achieve data augmentation.

7. The operational code odor identification method based on supervised contrastive learning according to claim 1, characterized in that, In S4, the classification layer network is a linear layer with a Softmax activation function, and the loss function used to train the classification layer network is the cross-entropy loss function.

8. An operable code odor identification system based on supervised contrastive learning, characterized in that, This method is used to implement the operational code odor identification method based on supervised contrastive learning as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the operable code odor identification method based on supervised contrastive learning as described in any one of claims 1 to 7.

10. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to, when executing the computer program, implement the operable code odor identification method based on supervised contrastive learning as described in any one of claims 1 to 7.

Images