Cross-programming language design bad smell identification method and device

Abstract

The invention discloses a cross-programming language design bad smell recognition method and device, and belongs to the technical field of computers.The method comprises the steps that a first code file set is obtained, the first code file set comprises a plurality of code files, and the code files comprise the code file achieved through a Python programming language and the code file achieved through a C / C + + programming language; analyzing the plurality of code files to determine language interaction boundary codes, the language interaction boundary codes including codes in a Python code file related to C / C + + interaction and codes in a C / C + + code file related to Python interaction; and based on the bad smell recognition rules in the bad smell recognition rule set, carrying out design bad smell recognition on the language interaction boundary code. By means of the method, the bad design smell existing in the Python and C / C + + cross-programming language can be accurately recognized.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method and device for identifying bad design smell across programming languages. Background Art

[0002] Design smell refers to some bad programming practices in the software development process. Design smell usually includes code smell and anti-pattern. Code smell is a problem that may occur at the code level, and anti-pattern is a higher-level design smell, which may involve a wider range of issues such as architecture, design or project management. Design smell is directly related to software maintainability. If there is a design smell, it will make the code more difficult to understand, modify and extend, increase maintenance costs and introduce potential errors. Therefore, it is necessary to accurately identify design smells to facilitate the subsequent correction of the identified design smells.

[0003] The design smell identification methods in the related art are usually applicable to the case where the code is in a single programming language. For cross-programming languages ​​(that is, the code includes two programming languages), there is only one method built by Abidi to identify cross-programming language design smells through static code analysis. This method parses the source code of Java and C / C++ through the srcML tool, addresses it through Xpath, and applies customized rules and thresholds to detect design smells in JNI software systems. However, this method is only applicable to cross-programming language situations such as Java and C / C++. When applied to other cross-programming language situations, some rules are not applicable. For example, for cross-programming language situations such as Python and C / C++, Abidi's method defines the design smell of unused methods. In Java, methods are contained in classes, so Abidi's method does not consider the case of unused classes; but in Python, classes and methods are two entities of the same granularity (same level), and only considering the design smell of unused methods will cause the design smell of unused classes to be missed.

[0004] In addition, due to the different grammatical rules of different languages, the srcML tool used by Abidi is only applicable to JNI systems (Java and C / C++); and due to the development of artificial intelligence, many software use the language combination of Python and C / C++, but srcML does not support the parsing of Python, resulting in problems when applying Abidi's method to the identification of design smells across programming languages ​​such as Python and C / C++. Summary of the invention

[0005] The present disclosure provides a method and device for identifying bad design smells in cross-programming languages, which can accurately identify bad design smells in cross-programming languages ​​such as Python and C / C++. The technical solution includes at least the following solutions: In a first aspect, a method for identifying design bad smells across programming languages ​​is provided, comprising: obtaining a first code file set, the first code file set comprising a plurality of code files, the plurality of code files comprising code files implemented in the Python programming language and code files implemented in the C / C++ programming language; analyzing the plurality of code files to determine language interaction boundary codes, the language interaction boundary codes comprising codes in Python code files involving C / C++ interactions and codes in C / C++ code files involving Python interactions; identifying design bad smells for the language interaction boundary codes based on bad smell identification rules in a bad smell identification rule set, the bad smell identification rules being determined based on design bad smells existing in the interaction process between the Python programming language and the C / C++ programming language.

[0006] Optionally, the bad smell identification rules include: the extension module is not used in Python, and the extension module is used to use Python / C API or Pybind11 to extend Python to C / C++; when the C / C++ function bound in the extension module is a long Lambda function, the length of the long Lambda function is greater than a length threshold; there are some unused local entities in the extension module, and the extension module includes multiple local entities, and the local entities include classes, functions, and variables used for interaction in the extension module; in the process of creating the extension module, an error detection operation is not performed on the process of adding objects; using Python / C When the extension module is written using the API, the function bound in the extension module lacks a static declaration; relative paths are not used when ctypes is imported and the dynamic link library is loaded; when the extension module is written using Pybind11, the sum of the number of functions directly bound to any class bound in the extension module and the number of functions indirectly bound using aliases is greater than the function number threshold; for any code file implemented in the Python programming language, the sum of the number of code files to which the C / C++ functions bound in the extension module called by the code file belong and the number of code files to which the C++ classes bound in the extension module called by the code file belong is greater than the file number threshold.

[0007] Optionally, analyzing the multiple code files to determine the language interaction boundary code includes: using the pylibscrml toolkit to parse a first type of code file into a first parsing result, the first type of code file being a code file in the first code file set implemented in the C / C++ programming language; using Python's built-in modules ast and _ast to parse a second type of code file into an abstract syntax tree, the second type of code file being a code file in the first code file set implemented in the Python programming language; querying the first parsing result and the abstract syntax tree to determine the language interaction boundary code.

[0008] Optionally, the querying the first parsing result and the abstract syntax tree to determine the language interaction boundary code includes: based on the abstract syntax tree, querying the code involved in the first process of PyThon calling C / C++ to determine the language interaction boundary code in the first process, the first process including the process of Python calling extension modules, local classes and local functions; based on the abstract syntax tree, querying the code involved in the second process of importing a dynamic link library in Python through ctypes to determine the language interaction boundary code in the second process, the second process including the process of importing a dynamic link library in a Windows operating system, the process of importing a dynamic link library in a Linux operating system and the process of importing a dynamic link library in a Unix operating system; based on the first parsing result, querying the code involved in the first process of using Python / C The code involved in the third process of building the extension module through the API is used to determine the language interaction boundary code in the third process, and the third process includes the definition and implementation of local functions, the construction of the method table, the definition of the extension module, and the initialization of the extension module; based on the first parsing result, the code involved in the fourth process of implementing cross-language binding using Pybind11 is queried to determine the language interaction boundary code in the fourth process, and the fourth process of cross-language binding includes binding local classes and local functions to the extension module directly or indirectly.

[0009] Optionally, the method further includes: generating a design smell report based on the result of the smell identification, wherein the design smell report includes code files where language interaction boundary codes with the design smell are located and the number of code lines where language interaction boundary codes with the design smell are located.

[0010] Optionally, the performing design bad smell identification on the language interaction boundary code based on the bad smell identification rules in the bad smell identification rule set includes: if a first language interaction boundary code satisfies any bad smell identification rule in the bad smell identification rule set, it indicates that the first language interaction boundary code has a design bad smell, and the first language interaction boundary code is any group of codes in the language interaction boundary codes.

[0011] In a second aspect, a device for identifying design bad smells across programming languages ​​is also provided, including: an acquisition module, used to acquire a first code file set, the first code file set including multiple code files, the multiple code files including code files implemented in Python programming language and code files implemented in C / C++ programming language; an analysis module, used to analyze the multiple code files to determine language interaction boundary codes, the language interaction boundary codes including codes in Python code files related to C / C++ interaction and codes in C / C++ code files related to Python interaction; a bad smell identification module, used to identify design bad smells for the language interaction boundary codes based on bad smell identification rules in a bad smell identification rule set, the bad smell identification rules being determined based on design bad smells existing in the interaction process between Python programming language and C / C++ programming language.

[0012] Optionally, the analysis module is also used to use the pylibscrml toolkit to parse a first type of code file into a first parsing result, wherein the first type of code file is a code file in the first code file set that is implemented in the C / C++ programming language; use Python's built-in modules ast and _ast to parse a second type of code file into an abstract syntax tree, wherein the second type of code file is a code file in the first code file set that is implemented in the Python programming language; and query the first parsing result and the abstract syntax tree to determine the language interaction boundary code.

[0013] Optionally, the analysis module is also used to query the code involved in the first process of PyThon calling C / C++ based on the abstract syntax tree to determine the language interaction boundary code in the first process, the first process including the process of Python calling the extension module, the local class and the local function; based on the abstract syntax tree, query the code involved in the second process of importing the dynamic link library in Python through ctypes to determine the language interaction boundary code in the second process, the second process including the process of importing the dynamic link library in the Windows operating system, the process of importing the dynamic link library in the Linux operating system and the process of importing the dynamic link library in the Unix operating system; based on the first parsing result, query the code involved in the third process of building the extension module using Python / C API to determine the language interaction boundary code in the third process, the third process including the definition and implementation of the local function, the construction of the method table, the definition of the extension module, and the initialization of the extension module; based on the first parsing result, query the code involved in the fourth process of using Pybind11 to implement cross-language binding to determine the language interaction boundary code in the fourth process, the fourth process of cross-language binding includes binding the local class and the local function to the extension module directly or indirectly.

[0014] Optionally, the device further includes: a generation module, configured to generate a design smell report based on the result of the smell identification, wherein the design smell report includes code files where language interaction boundary codes with the design smell are located and the number of code lines where language interaction boundary codes with the design smell are located.

[0015] Optionally, the bad smell identification module is further used to indicate that the first language interaction boundary code has a design bad smell if the first language interaction boundary code conforms to any bad smell identification rule in the bad smell identification rule set, and the first language interaction boundary code is any group of codes in the language interaction boundary codes.

[0016] In a third aspect, a computer device is also provided, including: a memory and a processor, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor, thereby executing the cross-programming language design smell identification method described in the above embodiment.

[0017] In a fourth aspect, a computer-readable storage medium is also provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor, thereby executing the cross-programming language design smell identification method described in the above embodiment.

[0018] In a fifth aspect, a computer program product is provided, comprising a computer program / instruction, wherein when the computer program / instruction is executed by a processor, the method described in the first aspect is implemented.

[0019] The beneficial effects brought by the technical solution provided by the embodiments of the present disclosure include at least: In the disclosed embodiment, the bad smell identification rules in the bad smell identification rule set are used to implement the bad smell identification of the language interaction boundary code in the first code file set. The first code file set includes code files implemented in the Python programming language and code files implemented in the C / C++ programming language. Since the bad smell identification rules are determined based on the design bad smells existing in the interaction process between the Python programming language and the C / C++ programming language, the design bad smells existing in the first code file set can be accurately identified, that is, the design bad smells existing in the cross-programming language such as Python and C / C++ can be accurately identified. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 A flowchart of a method for identifying bad design smell across programming languages ​​provided by an exemplary embodiment of the present disclosure is shown; Figure 2 A flowchart of a method for identifying bad design smell across programming languages ​​provided by another exemplary embodiment of the present disclosure is shown; Figure 3 This is a schematic diagram of the whole process of identifying design smells; Figure 4 A schematic diagram of the structure of a device for identifying bad design smell across programming languages ​​provided by an exemplary embodiment of the present disclosure is shown; Figure 5 It is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0022] Unless otherwise defined, the technical or scientific terms used herein shall have the usual meanings understood by persons of ordinary skill in the field to which the present disclosure belongs. The words "first", "second", "third" and similar words used in the patent application specification and claims of the present disclosure do not indicate any order, quantity or importance, but are only used to distinguish different components. Similarly, words such as "one" or "one" do not indicate a quantitative limitation, but rather indicate the presence of at least one. Words such as "include" or "comprise" and similar words mean that the elements or objects appearing before "include" or "comprises" cover the elements or objects listed after "include" or "comprises" and their equivalents, and do not exclude other elements or objects.

[0023] In order to make the objectives, technical solutions and advantages of the present disclosure more clear, the embodiments of the present disclosure will be further described in detail below with reference to the accompanying drawings.

[0024] In order to facilitate understanding of the embodiments of the present disclosure, the following explanations and annotations are given to the professional terms used in the embodiments of the present disclosure: Python / C API (Application Programming Interface): is an interaction mechanism between Python and C / C++ programming languages. Python / C API includes Python API, which enables C and C++ programmers to access Python interpreter at multiple levels. This API is also available in C / C++. To simplify the description, it is usually referred to as Python / C API.

[0025] Pybind11: Similar to Python / C API, Pybind11 is also an interaction mechanism across Python and C / C++ languages. Pybind11 is an open source library for creating Python bindings, which provides a simple and powerful API for encapsulating C++ code as Python modules.

[0026] ctypes: Similar to Python / C API and Pybind11, ctypes is also an interaction mechanism between Python and C / C++. ctypes is a standard library of Python that provides the ability to interact with C language libraries. Using ctypes, you can create, access, and modify C data types, load dynamic link libraries, and call functions defined in dynamic link libraries.

[0027] ExtensionModule(m): In the disclosed embodiment, ExtensionModule indicates the definition of an extension module. The name of the extension module is in brackets in ExtensionModule(). ExtensionModule(m) means that the name of the extension module is defined as m. IsExtensionModule(m) indicates that the extension module m exists.

[0028] True and False: True means true, False means false. For example, Python / CAPI=True means that the operation of using Python / CAPI to write C / C++ extension modules is true.

[0029] IsCalled(m): Called means being called in Python. Is before Called means the existence of the behavior of Called, that is, IsCalled means the existence of the behavior of being called in Python. IsCalled(m) means the behavior of the extension module m being called in Python. Similarly, IsCalled(alias) means the behavior of the alias alias being called in Python. IsCalled(f) means the behavior of the local function f being called in Python; IsCalled(alias(f)) means the behavior of the alias of the local function f being called in Python.

[0030] IsLoaded(m): Loaded means that the module is loaded in Python through LoadLibrary. Here, LoadLibrary is abbreviated as Loaded. IsLoaded(m) indicates that the extension module m is loaded in Python through LoadLibrary. Similarly, IsLoaded(alias) indicates that the alias is loaded in Python through LoadLibrary.

[0031] InBUILD(m,alias): BUILD means BUILD file, and InBUILD means in BUILD file. The alias in the brackets is the alias, which is at the same level as the name of the extension module m, so alias here means the alias of the extension module m; InBUILD(m,alias) means that the alias of the extension module m is configured in the BUILD file.

[0032] NativeFunction(f): NativeFunction means defining a native function. The name of the native function is in the brackets of NativeFunction (). NativeFunction (f) means defining a native function with the name f. IsNativeFunction means that a native function exists; IsNativeFunction (f) means that a native function f exists.

[0033] IsBound: Bound means binding, IsBound indicates the existence of a binding operation. IsBound(f) indicates the existence of an operation in which the local function f is bound.

[0034] IsLF(f): LF is Lambda Function. IsLF indicates the existence of a Lambda function. IsLF(f) also means that function f is a Lambda function.

[0035] Length(f): Length is the length, Length(f) is the length of function f.

[0036] MaxLengthOfLFThreshold (Max Length Of Lambda Function Threshold, maximum length threshold of Lambda function): In the embodiment of the present disclosure, MaxLengthOfLFThreshold is the length threshold.

[0037] NativeEntity(e): Similar to NativeFunction(f), NativeEntity(e) means defining a native entity. The name of the native entity is in the brackets of NativeEntity(). NativeEntity(e) means defining the name of the local entity as e. IsCalled(e) indicates that there is a behavior in which the native entity e is called in Python.

[0038] NativeClass(c): Similar to NativeFunction(f) and NativeEntity(e), NativeClass(c) means defining a native class. The name of the native class is in the brackets of NativeClass(). NativeClass(c) means defining a native class with the name c. IsNativeClass means that a native class exists; IsNativeClass(c) means that a native class c exists.

[0039] IsImported(e): Imported means imported in Python. IsImported means there is an operation of importing in Python. IsImported(e) means there is an operation of importing the local entity e in Python. Similarly, IsImported(ctypes) means there is an operation of importing ctypes in Python.

[0040] AddObject(AO): AddObject is used to define the operation of adding an object. The name of the operation of adding an object is in the brackets in AddObject(). AddObject(AO) means defining the name of the operation of adding an object as AO.

[0041] GetPyModule_AddObjectField: PyModule_AddObjectField is a field in the code file. This field is usually used to represent the operation of adding objects when the extension module is initialized. The Get before PyModule_AddObjectField represents the acquisition operation, that is, GetPyModule_AddObjectField represents the code for getting the PyModule_AddObjectField field.

[0042] CheckReturnValue(AO): CheckReturnValue means checking the return value, that is, CheckReturnValue(AO) means checking the return value of the AO operation.

[0043] InTryExcept(AO): TryExcept is also try / except, which means two code segments. InTryExcept is also in the try / except code segments. InTryExcept(AO) means AO is in the try / except code segments.

[0044] IsExtensionModuleByPython / CAPI: IsExtensionModule means that there is an extension module. ByPython / CAPI means that it is written in Python / CAPI. IsExtensionModuleByPython / CAPI means that there is an extension module written in Python / CAPI. Similarly, IsExtensionModuleByPybind11 means that there is an extension module written in Pybind11.

[0045] IsImplemented(f): Implemented means the implementation process, IsImplemented means the existence of the implementation process, IsImplemented(f) means the implementation process of the local function f exists, that is, it is in the implementation process of the local function f.

[0046] IsDeclaredStatic(f): DeclaredStatic means declared as a static variable, IsDeclaredStatic means there is an operation to declare it as a static variable, IsDeclaredStatic(f) means there is an operation to declare it as a static variable in the local function f.

[0047] LoadDLL(f(x)): DLL (Dynamic Link Library) is a module that contains functions and data. LoadDLL is the operation of loading the dynamic link library. f(x) represents several different ways of loading the dynamic link library. LoadDLL(f(x)) represents the operation of loading the dynamic link library in several different ways.

[0048] f(x)∊{GetcdllField,GetCDLLField,GetLoadLibraryField,GetwindllField,GetWinDLLField}. Among them, GetcdllField means loading the DLL field in C language format; GetCDLLField means loading the DLL field in C++ language format; GetLoadLibraryField means loading the DLL field in Python by LoadLibrary; GetwindllField means loading the DLL field in 32-bit Windows operating system; GetWinDLLField means loading the DLL field in 64-bit Windows operating system.

[0049] RelativePath: Indicates the situation where a relative path is used.

[0050] NBFunctions(c): NB stands for Number, which means quantity; NBFunctions is the number of bound functions, and NBFunctions(c) is the number of functions directly bound in class c. Similarly, NBFunctions(alias(c)) indicates the number of functions indirectly bound using aliases in class c.

[0051] MaxNBFunctionsThreshold (Max Number Functions Threshold, maximum threshold of the number of functions): In the embodiment of the present disclosure, MaxNBFunctionsThreshold is the function number threshold.

[0052] call(f): call is used to define the behavior of being called by a code file implemented in the Python programming language. call(f) is the local function f called by a code file implemented in the Python programming language. Similarly, call(c) is the local class c called by a code file implemented in the Python programming language.

[0053] IsCalled(c): IsCalled(c) is similar to IsCalled(f) and IsCalled(alias(f)), indicating that a local class c is called in Python. Similarly, IsCalled(alias(c)) indicates that an alias of a local class c is called in Python.

[0054] Unique: indicates a deduplication operation.

[0055] FileCalls(F,call(f)): FileCalls indicates the number of files in the calling process. In the brackets, the first F indicates File, and (F,call(f)) indicates the file to which the called local function f belongs. Therefore, FileCalls(F,call(f)) indicates the number of files to which the called local function f belongs. In actual applications, there are multiple local functions in the extension module that are called. Here, FileCalls(F,call(f)) does not refer to the number of files to which a certain called local function f belongs, but to the number of files to which all called local functions f belong. Similarly, FileCalls(F,call(c)) indicates the number of files to which the called local class c belongs. In actual applications, there are multiple local classes in the extension module that are called. Here, FileCalls(F,call(c)) does not refer to the number of files to which a certain called local class c belongs, but to the number of files to which all called local classes c belong.

[0056] MaxNBCallsFilesThreshold (Max Number Calls Files Threshold, maximum threshold of called files): In the embodiment of the present disclosure, MaxNBCallsFilesThreshold is the file number threshold.

[0057] Figure 1 A flowchart of a method for identifying bad design smell across programming languages ​​provided by an exemplary embodiment of the present disclosure is shown, and the method can be executed by a computer device. Figure 1 , the method comprising: In step 101, a first code file set is obtained.

[0058] The first code file set includes multiple code files, and the multiple code files include code files implemented in Python programming language and code files implemented in C / C++ programming language.

[0059] In the disclosed embodiment, the code files in the first code file set belong to the same software system, that is, the software system is jointly developed based on the Python programming language and the C / C++ programming language.

[0060] In the disclosed embodiment, the code files in the first code file set are the code files that need to be identified for design smell, and can be obtained in any way. For example, the code hosting platform GitHub can be crawled, and projects whose main programming languages ​​are Python and C / C++ can be found according to the programming language composition of the projects in GitHub, and the source code packages of the projects can be downloaded. The source code packages are the first code file set. In step 102, a plurality of code files are analyzed to determine language interaction boundary codes.

[0061] Language interaction boundary code includes code in Python code files that involves C / C++ interaction and code in C / C++ code files that involves Python interaction.

[0062] Common cross-language interactive communication mechanisms include Python / C API, Pybind11, and ctypes. When detecting language interaction boundary codes, it is also necessary to detect the codes involved when using the above three mechanisms.

[0063] The language interaction boundary code can be extracted as an intermediate result, which includes the modules, classes, functions and related information of cross-language interaction customized by developers in the software system, as well as the calling information of external files to local entities.

[0064] In step 103, design smells are identified for the language interaction boundary code based on the smell identification rules in the smell identification rule set.

[0065] The bad smell identification rules are determined based on the design bad smells existing in the interaction process between Python programming language and C / C++ programming language. The bad smell identification rules in the bad smell identification rule set can be modified as required.

[0066] Optionally, when performing bad smell identification, a list of ignored sensitive keywords can be established so that sensitive keywords can be easily added or deleted. For example, "python", which is a keyword inside the Python compiler, is a sensitive keyword.

[0067] During the code execution, the compiler will distinguish these keywords based on their import. However, in the disclosed embodiment, since the code is not compiled but the design smell is directly identified based on the source code (that is, the design smell is identified based on the static analysis of the code), this will cause the pattern matching-based method to misjudge these keywords. Therefore, a list of ignored sensitive keywords can be established, and the sensitive keywords can be ignored during the design smell identification process, thereby improving the accuracy of design smell identification.

[0068] In the disclosed embodiment, the bad smell identification rules in the bad smell identification rule set are used to implement the bad smell identification of the language interaction boundary code in the first code file set. The first code file set includes code files implemented in the Python programming language and code files implemented in the C / C++ programming language. Since the bad smell identification rules are determined based on the design bad smells existing in the interaction process between the Python programming language and the C / C++ programming language, the design bad smells existing in the first code file set can be accurately identified, that is, the design bad smells existing in the cross-programming language such as Python and C / C++ can be accurately identified.

[0069] Figure 2 A flowchart of a method for identifying bad design smell across programming languages ​​provided by another exemplary embodiment of the present disclosure is shown, and the method can be executed by a computer device. Figure 2 , the method comprising: In step 201, a first code file set is obtained.

[0070] The relevant contents of step 201 refer to the aforementioned step 101, and the detailed description is omitted here.

[0071] In step 202, a plurality of code files in the first code file set are analyzed to determine language interaction boundary codes.

[0072] The language interaction boundary code includes the code in the Python code file that involves C / C++ interaction and the code in the C / C++ code file that involves Python interaction; Optionally, step 202 includes the following steps ac: Step a: using the pylibscrml toolkit to parse the first type of code file into a first parsing result.

[0073] The first category of code files are code files in the first code file set that are implemented in the C / C++ programming language. Optionally, the first category of code files is determined by the suffix of the code file, for example, by implementing a file processor to determine the first category of code files by the suffix of the code file. The suffixes of code files implemented in the C / C++ programming language include the four suffixes: ".c", ".cpp", ".cc", and ".h". If the suffix of a code file is any of the above four suffixes, it means that the code file is a first category of code files.

[0074] pylibscrml is a Python binding for srcML. It provides a Python interface to operate srcML files. Through the pylibscrml toolkit, you can use Python scripts to process and analyze source code. For example, you can parse the first type of code file and store the parsed results in an XML file, which is the first parsed result.

[0075] During implementation, a C / C++ file parser may be used to call pylibscrml to parse the first type of code file into a first parsing result. Step b, using Python's built-in modules ast and _ast, parse the second type of code file into an abstract syntax tree.

[0076] The second type of code file is a code file implemented in the Python programming language in the first code file set. Optionally, the second type of code file is determined by the suffix of the code file, for example, by using a file processor to determine the second type of code file by the suffix of the code file. The suffix of the code file implemented in the Python programming language includes: ".py". If the suffix of a code file is ".py", it means that the code file is a second type of code file.

[0077] During implementation, the Python file parser may be used to call ast and _ast to parse the second type of code file into an abstract syntax tree. Step c: query the first parsing result and the abstract syntax tree to determine the language interaction boundary code.

[0078] Optionally, when querying, for the first parsing result, a regular expression and XPath are used for matching query; for the abstract syntax tree, the query is performed by traversing the abstract syntax tree.

[0079] There are many implementation methods for traversing the abstract syntax tree to perform queries in the related technologies, and detailed description is omitted here.

[0080] Optionally, step c includes the following four steps: In the first step, based on the abstract syntax tree, the code involved in the first process of PyThon's call to C / C++ is queried to determine the language interaction boundary code in the first process.

[0081] The first process includes Python's calls to extension modules, native classes, and native functions.

[0082] In the second step, based on the abstract syntax tree, the code involved in the second process of importing the dynamic link library in Python through ctypes is queried to determine the language interaction boundary code in the second process.

[0083] The second process includes a process of importing a dynamic link library in a Windows operating system, a process of importing a dynamic link library in a Linux operating system, and a process of importing a dynamic link library in a Unix operating system.

[0084] The third step is to query the code involved in the third process of building the extension module using the Python / C API based on the first parsing result to determine the language interaction boundary code in the third process.

[0085] The third process includes the definition and implementation of local functions, the construction of method tables, the definition of extension modules, and the initialization of extension modules.

[0086] The fourth step is to query the code involved in the fourth process of implementing cross-language binding using Pybind11 based on the first parsing result to determine the language interaction boundary code in the fourth process.

[0087] The fourth process includes binding the local classes and local functions to the extension module directly or indirectly.

[0088] In Pybind11, local classes and local functions are directly bound to extension modules, including macro direct binding; in Pybind11, local classes and local functions are indirectly bound to extension modules, including indirect binding after function encapsulation and indirect binding of classes through aliases during function binding.

[0089] Among them, the first step, the third step and the fourth step are used to query the language interaction boundary code related to the extension module, and the second step is used to query the language interaction boundary code related to the dynamic link library.

[0090] During implementation, a language interface detector can be used to query the Python / CAPI and Pybind11 related codes involved in the first parsing result respectively, and the first process of querying PyThon's call to C / C++ and the related code of ctypes can be queried by querying the abstract syntax tree to determine the language interaction boundary code.

[0091] In step 203, design smells are identified for the language interaction boundary code based on the smell identification rules in the smell identification rule set.

[0092] Optionally, step 203 further includes: performing design smell identification on the language interaction boundary code based on the bad smell identification rules in the bad smell identification rule set and the configuration files in the first code file set.

[0093] In implementation, it is necessary to first extract configuration files of multiple code files in the first code file set, so as to identify design smell of language interaction boundary code. Exemplarily, a file processor may be used to extract configuration files of multiple code files in the first code file set.

[0094] The smell identification rules are based on the design smells existing in the interaction between Python programming language and C / C++ programming language.

[0095] Optionally, the bad smell identification rule set includes 8 bad smell identification rules in total. The 8 bad smell identification rules and their implementation methods are described below respectively.

[0096] Bad smell identification rule 1: Extension modules are not used in Python.

[0097] Extension modules are used to extend Python with C / C++ using the Python / C API or Pybind11.

[0098] When using Python / C API or Pybind11 to extend Python with C / C++, you need to write an extension module. If the extension module is not used in Python, it will cause a bad design.

[0099] Optionally, bad smell identification rule 1 is implemented by the following code: ExtensionModule(m):Python / CAPI=True OR Pybind11=True; used to define a local extension module m, indicating a C / C++ extension module written using Python / C API or Pybind11.

[0100] IsCalled(m)=False AND IsLoaded(m)=False OR; used to detect that the extension module m is not called in Python and is not loaded through LoadLibrary.

[0101] InBUILD(m,alias)=True AND IsCalled(alias)=False ANDIsLoaded(alias)=False; used to detect that the extension module alias is configured in the BUILD file and the alias is not called and loaded.

[0102] Bad smell identification rule 2: When the C / C++ function bound in the extension module is a long Lambda function, the length of the long Lambda function is greater than the length threshold.

[0103] Optionally, the 80 characters set by Chen is used as the default value of the length threshold. In actual applications, the value of the length threshold can also be modified as required.

[0104] In Pybind11, m.def represents module-level function binding, which mainly includes two parameters: parameter 1 and parameter 2. Parameter 1 is used to represent the function name to be used in Python, and parameter 2 is the C / C++ function corresponding to the function name. Developers often use Lambda function to represent parameter 2. When the length of Lambda expression exceeds a certain threshold, a bad design will occur.

[0105] Optionally, bad smell identification rule 2 is implemented by the following code: NativeFunction(f): IsBound=True AND IsExtensionModule(m) =True; used to define the extension module m, and define the function f as a function bound to the extension module, so the function f is a local function.

[0106] IsLF(f)=TrueAND Length(f)>MaxLengthOfLFThreshold; used to detect when the function f is a Lambda function and the length of the function is greater than the length threshold, where MaxLengthOfLFThreshold is the length threshold.

[0107] Bad smell identification rule 3: There are some unused local entities in the extension module.

[0108] Here, the extension module includes multiple local entities, and the local entities include classes, functions, variables, etc. used for interaction in the extension module.

[0109] Bad smell identification rule 3 is similar to bad smell identification rule 1, but the granularity is different. When an extension module is used, it does not mean that all entities in the module are used. Only when every entity in the extension module is not used, the module is considered an unused extension module (that is, it meets bad smell identification rule 1). The situation where some local entities in the extension module are used and some local entities are not used falls under bad smell identification rule 3.

[0110] Optionally, bad smell identification rule 3 is implemented by the following code: NativeEntity(e): IsNativeFunction=True OR IsNativeClass=True; used to define a native entity e, which includes NativeFunction (that is, the local function f in bad smell identification rule 2) and NativeClass (that is, a class c in the extension module in bad smell identification rule 7).

[0111] IsCalled(e)=False AND IsImported(e)=False; used to detect that the local entity has not been called by Python and has not been imported.

[0112] Bad smell identification rule 4: No error detection is performed on the process of adding objects during the creation of the extension module.

[0113] In the disclosed embodiment, bad smell identification rule 4 is used to detect the situation where the AO return value is false and AO does not exist in the try / except code segment. The process of creating an extension module includes the operation of adding an object (AddObject, AO) when the extension module is initialized, which is represented as the PyModule_AddObject field in the code file. In actual applications, if bad smell identification rule 4 is met, it means that there is a design bad smell in which the error detection operation of the process of adding objects is not performed during the process of creating an extension module.

[0114] Optionally, bad smell identification rule 4 is implemented by the following code: AddObject(AO):GetPyModule_AddObjectField; used to define AO ​​operations.

[0115] CheckReturnValue(AO)=False AND InTryExcept(AO)=False; used to detect that the AO return value is false and that AO does not exist in the try / except code segment.

[0116] Bad smell identification rule 5: When writing extension modules using the Python / C API, the functions bound in the extension module lack static declarations.

[0117] When writing extension modules in C / C++ using Python / C API, if the C / C++ functions bound to the extension module are not declared as static (declared as static variables), naming conflicts may occur with functions of other extension modules, affecting the portability and scalability of the system.

[0118] Optionally, bad smell identification rule 5 is implemented by the following code: IsExtensionModuleByPython / CAPI=True AND IsBound(f)=True; used to define a C / C++ function f bound in an extension module written using the Python / C API.

[0119] AND IsImplemented(f)=True AND IsDeclaredStatic(f)=False; used to detect the situation where the C / C++ function f is not statically declared (that is, not declared as static) during implementation.

[0120] Bad smell identification rule 6: Relative paths are not used when importing ctypes and loading dynamic link libraries.

[0121] When using ctypes, if the developer specifies the dynamic link library to be loaded by only a name or using an absolute path (that is, not using a relative path), a bad design will occur.

[0122] Optionally, bad smell identification rule 6 is implemented by the following code: IsImported(ctypes)=True AND LoadDLL(f(x))=True AND RelativePath=False; used to detect the situation where relative paths are not used during the process of importing ctypes and loading dynamic link libraries.

[0123] f(x)∊{GetcdllField,GetCDLLField,GetLoadLibraryField,GetwindllField,GetWinDLLField}; f(x) is used to define several different ways of loading dynamic link libraries.

[0124] Bad smell identification rule 7: When using Pybind11 to write an extension module, the sum of the number of functions directly bound by any class bound in the extension module and the number of functions indirectly bound using aliases is greater than the function number threshold.

[0125] When the sum of the number of functions directly bound in a class c and the number of functions indirectly bound by class c using aliases is greater than the set function number threshold, it will lead to a bad design.

[0126] Among them, there are many ways to bind functions, but they all start with def, such as def, def_readwrite, def_readonly, def_property, def_property_readonly, def_static, def_property_static, def_property_readonly_static, etc. When counting the number of functions bound in class c, the number of built-in functions is not considered, because these functions are called by the Python parser in specific situations, rather than directly by developers, and developers usually do not need to consider their size. Here, built-in functions are functions that start and end with double underscores in Python. The function number threshold (MaxNBFunctionsThreshold) uses the value of 7 set by Abidi et al. In the paper by Lippert and Roock, 7 is regarded as the number of objects that the human brain can understand. In implementation, the function number threshold can also be modified according to actual needs. For example, the value range of the function number threshold is 6~9, and the function number threshold is an integer.

[0127] Optionally, bad smell identification rule 7 is implemented by the following code: NativeClass(c):IsExtensionModuleByPybind11=True AND IsBound=True; a class c is a class bound in an extension module written using Pybind11.

[0128] NBFunctions(c)+NBFunctions(alias(c))>MaxNBFunctionsThreshold; used to detect the situation where the sum of the number of directly bound functions (NBFunctions(c)) and the number of indirectly bound functions using aliases (NBFunctions(alias(c))) in class c is greater than the function number threshold.

[0129] Bad smell identification rule 8: For any code file implemented in Python programming language, the sum of the number of code files to which the C / C++ functions bound in the extension module called by the code file belong and the number of code files to which the C++ classes bound in the extension module called by the code file belong is greater than the file quantity threshold.

[0130] Here, the C / C++ functions bound in the extension module are local functions, and the C++ classes bound in the extension module are local classes. This bad smell identification rule 8 is used to explain that if a Python code file calls too many local C / C++ entities (such as functions and classes) without proper optimization, it will increase the coupling between the Python code file and multiple C / C++ code files, resulting in design bad smell.

[0131] Optionally, bad smell identification rule 8 is implemented by the following code: call(f): IsNativeFunction(f)=True AND (IsCalled(f)=True OR IsCalled(alias(f))=True); used to define function f, which is a native function (that is, a C / C++ function bound in an extension module, which has the same meaning as NativeFunction(f) in bad smell identification rule 2). call(f) means that function f is called by a code file implemented in Python programming language, for example, directly or an alias is set when it is imported and the alias is called.

[0132] call(c): IsNativeClass(c)=True AND (IsCalled(c)=True ORIsCalled(alias(c))=True); is used to define class c, which is a native class (that is, a C++ class bound in an extension module, which has the same meaning as NativeClass(c) in bad smell identification rule 7). call(c) means that class c is called by a code file implemented in Python programming language, for example, directly or an alias is set when it is imported and the alias is called.

[0133] Unique(FileCalls(F,call(f))+FileCalls(F,call(c)))>MaxNBCallsFilesThreshold; used to detect the situation where the sum of the number of code files to which the called local function belongs (FileCalls(F,call(f))) and the number of code files to which the local class called by the code file belongs (FileCalls(F,call(c))) is greater than the file number threshold (MaxNBCallsFilesThreshold). Unique is used to remove duplicates when counting.

[0134] In the embodiment of the present disclosure, regarding the application of the cross-language mechanism, bad smell identification rules 1, 3, 4, 5, and 8 apply Python / C API, bad smell identification rules 1, 2, 3, 7, and 8 apply Pybind11, and rule 6 applies ctypes. In terms of the programming languages ​​involved, rules 2, 4, 5, and 7 only involve C / C++ code detection, rule 6 only involves Python code detection, and rules 1, 3, and 8 involve code detection on both Python and C / C++ ends.

[0135] During implementation, step 203 may be implemented by using a design smell detector, which is used to detect design smells existing in language interaction boundary codes and configuration files.

[0136] In the process of detecting design bad smells using the above 8 bad smell identification rules, if the first language interaction boundary code meets any bad smell identification rule in the bad smell identification rule set, it means that the first language interaction boundary code has a design bad smell. The first language interaction boundary code is any set of codes in the language interaction boundary code. At this time, step 204 can be performed on the first language interaction boundary code to store the identified design bad smell in the design bad smell report.

[0137] In step 204, a design smell report is generated based on the result of the smell identification.

[0138] The design smell report includes the code files where the language interaction boundary codes with the design smell are located and the number of code lines where the language interaction boundary codes with the design smell are located.

[0139] For example, if it is identified that the first language interaction boundary code has a design smell, the code file where the first language interaction boundary code is located and the number of code lines where the language interaction boundary code with the design smell is located are stored in the design smell report.

[0140] In the disclosed embodiment, eight bad smell identification rules are used to identify bad smells in the code files in the first code file set, without manual search, to achieve automatic bad smell detection. The cross-programming language design bad smell identification method in the disclosed embodiment can detect design bad smells in three cross-language communication mechanisms with strong versatility in Python and C / C++ systems (i.e., Python / C API, Pybind11 and ctypes) and generate a design bad smell report, providing convenience for users to further analyze multi-language systems.

[0141] In addition, when identifying bad design smells, the cross-programming language design smell identification method in the embodiment of the present disclosure only needs to provide the source code package (that is, the first code file set) of the multi-language software system, without the need to compile the system, which reduces the detection cost and can report the relevant information of the bad smell in detail. It has been verified by experiments that when the cross-programming language design smell identification method in the embodiment of the present disclosure is used to detect bad design smells, the detection accuracy reaches 98.17%.

[0142] Figure 3 This is a schematic diagram of the whole process of identifying design smells. Figure 3 As shown, when identifying design smells, a source code package (that is, a first code file set) is first obtained. The source code package can be extracted from a deep learning framework, for example.

[0143] Then the source code package is preprocessed. The preprocessing includes first inputting the source code package into a file processor so as to divide the code files in the source code package into C / C++ code files (first type of code files) and Python code files (second type of code files). In addition, the file processor is also used to extract configuration files from the source code package. Then the C / C++ code file is input into a C / C++ file parser, and the C / C++ file parser is used to call the pylibscrml toolkit to parse the C / C++ code file to obtain a first parsing result; and the Python code file is input into a Python file parser, and the Python file parser is used to call ast and _ast to parse the Python code file to obtain an abstract syntax tree.

[0144] Then the source code package is core processed. The core processing includes inputting the first parsing result and the abstract syntax tree obtained by preprocessing into the language interface detector. The language interface detector is used to query Python / CAPI and Pybind11 based on the first detection result to determine the language interaction boundary code in the first detection result, and query the first process of PyThon's call to C / C++ and the code involved in ctypes based on the abstract syntax tree to determine the language interaction boundary code in the abstract syntax tree, thereby obtaining the language interaction boundary code in the first code file set. After determining the language interaction boundary code, the language interface detector inputs the language interaction boundary code into the design smell detector, and the file processor also inputs the extracted configuration file into the design smell detector. The design smell detector is used to identify design smells using predefined rules and thresholds (8 smell identification rules in the smell identification rule set). Finally, the detection result can be output. The detection result (design smell report) can include 8 cross-language design smells, and the format of the detection result can be csv format.

[0145] The following are device embodiments of the present application. For details not described in detail in the device embodiments, reference may be made to the above method embodiments.

[0146] Figure 4 A schematic diagram of the structure of a device for identifying bad design smell across programming languages ​​provided by an exemplary embodiment of the present disclosure is shown. Figure 4 The cross-programming language design bad smell identification device 400 includes: an acquisition module 401, an analysis module 402 and a bad smell identification module 403.

[0147] The acquisition module 401 is used to acquire a first code file set, the first code file set includes multiple code files, and the multiple code files include code files implemented in Python programming language and code files implemented in C / C++ programming language.

[0148] The analysis module 402 is used to analyze multiple code files to determine language interaction boundary codes, which include codes in Python code files related to C / C++ interaction and codes in C / C++ code files related to Python interaction.

[0149] The bad smell identification module 403 is used to identify design bad smells on language interaction boundary codes based on bad smell identification rules in a bad smell identification rule set. The bad smell identification rules are determined based on design bad smells existing in the interaction process between Python programming language and C / C++ programming language.

[0150] Optionally, the analysis module 402 is also used to use the pylibscrml toolkit to parse the first type of code files into a first parsing result, the first type of code files are code files in the first code file set that are implemented in the C / C++ programming language; use Python's built-in modules ast and _ast to parse the second type of code files into an abstract syntax tree, the second type of code files are code files in the first code file set that are implemented in the Python programming language; query the first parsing result and the abstract syntax tree to determine the language interaction boundary code.

[0151] Optionally, the analysis module 402 is also used to query the code involved in the first process of PyThon calling C / C++ based on the abstract syntax tree to determine the language interaction boundary code in the first process, the first process includes the process of Python calling the extension module, the local class and the local function; based on the first parsing result, query the code involved in the second process of importing the dynamic link library in Python through ctypes to determine the language interaction boundary code in the second process, the second process includes the process of importing the dynamic link library in the Windows operating system, the process of importing the dynamic link library in the Linux operating system, and the process of importing the dynamic link library in the Unix operating system; based on the first parsing result, query the code involved in the third process of building the extension module using the Python / C API to determine the language interaction boundary code in the third process, the third process includes the definition and implementation of the local function, the construction of the method table, the definition of the extension module, and the initialization of the extension module; based on the first parsing result, query the code involved in the fourth process of using Pybind11 to implement cross-language binding to determine the language interaction boundary code in the fourth process, the fourth process of cross-language binding includes binding the local class and the local function to the extension module directly or indirectly.

[0152] Optionally, the device further includes: a generation module 404, for generating a design smell report based on the result of the smell identification, wherein the design smell report includes the code file where the language interaction boundary code with the design smell is located and the number of code lines where the language interaction boundary code with the design smell is located.

[0153] Optionally, the bad smell identification module 403 is further configured to indicate that the first language interaction boundary code has a design bad smell if the first language interaction boundary code satisfies any bad smell identification rule in a bad smell identification rule set, and the first language interaction boundary code is any set of codes in the language interaction boundary codes.

[0154] It should be noted that: when the cross-programming language design bad smell identification device provided in the above embodiment performs the cross-programming language design bad smell identification, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the cross-programming language design bad smell identification device provided in the above embodiment and the cross-programming language design bad smell identification method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0155] The division of modules in the embodiments of the present disclosure is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional module in each embodiment of the present disclosure may be integrated into a processor, or may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0156] If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a terminal device (which can be a personal computer, mobile phone, or communication device, etc.) or a processor (processor) to execute all or part of the steps of the method of each embodiment of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0157] Figure 5 Schematic diagram of the structure of the computer device provided by the embodiment of the present disclosure. Figure 5 As shown, the computer device 500 includes: a processor 501 and a memory 502 .

[0158] The processor 501 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 501 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 501 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 501 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 501 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0159] The memory 502 may include one or more computer-readable storage media, which may be non-transitory. The memory 502 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 502 is used to store at least one instruction, which is used to be executed by the processor 501 to implement the cross-programming language design bad smell identification method provided in the embodiments of the present disclosure.

[0160] Those skilled in the art will understand that Figure 5 The structure shown in the figure does not constitute a limitation on the computer device 500, and the computer device 500 may include more or less components than those shown in the figure, or combine some components, or adopt a different arrangement of components.

[0161] The embodiments of the present disclosure also provide a non-temporary computer-readable storage medium. When the instructions in the storage medium are executed by a processor of a computer device, the computer device is able to execute the method for identifying design smells across programming languages ​​provided in the embodiments of the present disclosure.

[0162] The embodiments of the present disclosure also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the method for identifying design smell across programming languages ​​provided in the embodiments of the present disclosure.

[0163] The above description is only an optional embodiment of the present disclosure and is not intended to limit the present disclosure. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A method for identifying bad design smell across programming languages, characterized in that: The method comprises: Obtain a first code file set, wherein the first code file set includes a plurality of code files, wherein the plurality of code files include code files implemented in the Python programming language and code files implemented in the C / C++ programming language; Analyze the multiple code files to determine language interaction boundary codes, wherein the language interaction boundary codes include codes in Python code files related to C / C++ interaction and codes in C / C++ code files related to Python interaction; Based on the bad smell identification rules in the bad smell identification rule set, the language interaction boundary code is subjected to design bad smell identification, wherein the bad smell identification rules are determined based on the design bad smell existing in the interaction process between the Python programming language and the C / C++ programming language.

2. The method according to claim 1, characterized in that The bad smell identification rules include: The extension module is not used in Python. The extension module is used to extend Python with C / C++ using Python / C API or Pybind11. When the C / C++ function bound in the extension module is a long Lambda function, the length of the long Lambda function is greater than a length threshold; There are some unused local entities in the extension module, the extension module includes multiple local entities, and the local entities include classes, functions, and variables used for interaction in the extension module; Failure to perform error detection on the process of adding objects during the creation of the extension module; When the extension module is written using Python / C API, the functions bound in the extension module lack static declarations; Relative paths are not used when importing ctypes and loading dynamic link libraries; When the extension module is written using Pybind11, the sum of the number of functions directly bound to any class bound in the extension module and the number of functions indirectly bound using aliases is greater than the function number threshold; For any code file implemented in the Python programming language, the sum of the number of code files to which the C / C++ functions bound in the extension module called by the code file belong and the number of code files to which the C++ classes bound in the extension module called by the code file belong is greater than the file number threshold.

3. The method according to claim 1 or 2, characterized in that: The analyzing the multiple code files to determine the language interaction boundary code includes: The pylibscrml toolkit is used to parse the first type of code files into a first parsing result, wherein the first type of code files are code files in the first code file set that are implemented in the C / C++ programming language; Using Python's built-in modules ast and _ast, parsing the second type of code files into abstract syntax trees, where the second type of code files are code files in the first code file set that are implemented in the Python programming language; The first parsing result and the abstract syntax tree are queried to determine the language interaction boundary code.

4. The method according to claim 3, characterized in that The querying the first parsing result and the abstract syntax tree to determine the language interaction boundary code includes: Based on the abstract syntax tree, query the code involved in the first process of PyThon calling C / C++ to determine the language interaction boundary code in the first process, wherein the first process includes the process of Python calling the extension module, the native class and the native function; Based on the abstract syntax tree, query the code involved in the second process of importing the dynamic link library in Python through ctypes to determine the language interaction boundary code in the second process, wherein the second process includes a process of importing the dynamic link library in a Windows operating system, a process of importing the dynamic link library in a Linux operating system, and a process of importing the dynamic link library in a Unix operating system; Based on the first parsing result, query the code involved in the third process of building the extension module using Python / C API to determine the language interaction boundary code in the third process, wherein the third process includes the definition and implementation of the local function, the construction of the method table, the definition of the extension module, and the initialization of the extension module; Based on the first parsing result, query the code involved in the fourth process of implementing cross-language binding using Pybind11 to determine the language interaction boundary code in the fourth process, and the fourth process of cross-language binding includes binding local classes and local functions to the extension module directly or indirectly.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: Based on the result of the bad smell identification, a design bad smell report is generated, wherein the design bad smell report includes code files where language interaction boundary codes with the design bad smell are located and the number of code lines where the language interaction boundary codes with the design bad smell are located.

6. The method according to claim 1 or 2, characterized in that: The step of identifying design bad smells on the language interaction boundary code based on the bad smell identification rules in the bad smell identification rule set includes: If the first language interaction boundary code conforms to any bad smell identification rule in the bad smell identification rule set, it means that the first language interaction boundary code has a design bad smell, and the first language interaction boundary code is any group of codes in the language interaction boundary codes.

7. A device for identifying bad design smell across programming languages, characterized in that: The device comprises: An acquisition module, configured to acquire a first code file set, wherein the first code file set includes a plurality of code files, wherein the plurality of code files include code files implemented in Python programming language and code files implemented in C / C++ programming language; An analysis module, configured to analyze the plurality of code files to determine language interaction boundary codes, wherein the language interaction boundary codes include codes in Python code files related to C / C++ interaction and codes in C / C++ code files related to Python interaction; A bad smell identification module is used to identify design bad smells on the language interaction boundary code based on bad smell identification rules in a bad smell identification rule set, wherein the bad smell identification rules are determined based on design bad smells existing in the interaction process between the Python programming language and the C / C++ programming language.

8. A computer device, characterized in that: The computer device comprises: a memory and a processor, wherein at least one computer program is stored in the memory, and the at least one computer program is loaded and executed by the processor to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by a processor to implement the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images