MétaCan
Menu
Retour à la cohorte
Enregistrement W6930587237 · doi:10.5281/zenodo.14279534

DPy: Code Smells Detection Tool for Python

2024· other· en· W6930587237 sur OpenAlexaff

Notice bibliographique

RevueZenodo (CERN European Organization for Nuclear Research) · 2024
Typeother
Langueen
DomaineBiochemistry, Genetics and Molecular Biology
ThématiqueForensic and Genetic Research
Établissements canadiensDalhousie University
Organismes subventionnairesnon disponible
Mots-clésPython (programming language)ExecutableDirectorySource codeScripting languageCode smellGraphical user interface

Résumé

récupéré en direct d'OpenAlex

DPy is a static analysis tool designed to detect code smells in Python codebases. It identifies code smells belonging to implementation and design granularities. Features A comprehensive set of supported code smells: The tool detects many implementation and design smells. Configurable thresholds: User may enable/disable the detection of a smell. Also, the used thresholds are customizable. Detailed reporting: Provides detailed reports including the source code entity (such as package, module, class, and function), location, and detected smell type. Export formats: Supports exporting results in JSON and CSV formats for easy integration with other tools and workflows. Folder Descriptions dit_analysis/ This folder includes the analysis and results of the Depth of Inheritance (DIT) for the top-10 Python projects analyzed with DPy. DPy/ Contains executables for both Windows and Unix-like systems (e.g., Linux and Mac). human_evaluation/ Datasets collected through manual evaluation efforts. projects/ Contains information and results of projects used for human evaluation. verbosity_conversion/ Includes the analysis and datasets for verbosity conversion between Python and Java. Installation This guide will help you add the DPy executable to your system's PATH so you can run it from any terminal or command prompt. Windows Installation Move the Executable to a Directory: Copy the DPy/DPy-windows-v0.0.7.exe/DPy.exe file to a directory of your choice, such as C: \DPy. Add the Directory to PATH: Press Win + R, type sysdm.cpl, and press Enter. Go to the Advanced tab and click on Environment Variables. Under System Variables, find the variable Path and select it, then click Edit. Click New and add the path to the directory where DPy.exe is located (e.g., C: \DPy). Click OK to save and close all dialogs. Verify the Installation: Open a new Command Prompt (Win + R, type cmd, and press Enter). Type DPy and press Enter. If installed correctly, the program will execute. Linux and macOS Installation Move the Executable to a Directory: Copy the DPy/DPy-ubuntu-v0.0.7/DPy file to a directory, such as /usr/local/bin or a custom directory like ~/DPy: bash cp DPy /usr/local/bin Make the File Executable (if not already): Run the following command: bash chmod +x /usr/local/bin/DPy Add the Directory to PATH (if using a custom directory): Open your shell configuration file (e.g., ~/.bashrc, ~/.zshrc, or ~/.profile) in a text editor: bash nano ~/.bashrc Add the following line to include the directory in the PATH: bash export PATH="$PATH:~/DPy" Save the file and reload the shell: bash source ~/.bashrc Verify the Installation: Open a new terminal and type DPy --version. If installed correctly, the program will execute. Notes for macOS Users: macOS often uses zsh as the default shell (since macOS Catalina). Make sure you update the correct shell configuration file (~/.zshrc). If /usr/local/bin is not writable, you can use /opt/homebrew/bin if you have Homebrew installed, or create a custom directory in your home directory (e.g., ~/DPy). Uninstallation To remove DPy : Windows: Delete the executable from the directory where it was stored. Remove the directory from PATH in the Environment Variables settings. Linux and macOS: Delete the executable from the directory (e.g., /usr/local/bin or your custom directory). Remove the PATH entry from your shell configuration file if applicable. Usage Once installed, you may invoke the tool using analyze command. Use help option to see all the available options. DPy analyze --help The above command should result in an output something similar to the following. │ * --input -i TEXT The path to the input Python file or directory for analysis. [default: None] [required] │ │ * --output -o TEXT The path to the directory where results will be saved. [default: None] [required] │ │ --format -f TEXT The output format for results, e.g., 'json' or 'csv'. [default: json] │ │ --config -c TEXT The path to a custom configuration file. If not provided, defaults to 'default_config.json' in the script directory. [default: None] │ │ --log_dir -l TEXT The directory to store log files. Defaults to the output directory if not specified. [default: None] │ │ --help Show this message and exit. Run the following command to analyze a Python project DPy analyze -i /path/to/your/python/project -o /path/to/output/directory Customization You may customize the detection thresholds for smells and other settings by providing a JSON configuration file. An example partial json file is presented here. { "Smells": { "BrokenHierarchy": { "enable": true }, "BrokenModularization": { "enable": true, "min_fields": 5 }, "ComplexConditional": { "enable": true, "max_conditions": 2 } } } Supported code quality metrics Class/Module-level metrics Along with the package name, module name, and class name, the tool provides the following code quality metrics for each class/module: LOC: Lines of code NOM: Number of methods NOPM: Number of public methods WMC: Weighted methods for class NOF: Number of fields LCOM: Lack of cohesion among methods Fan-in: Incoming (class) dependencies Fan-out: Outgoing (class) dependencies DIT: Depth of inheritance Method/Function-level metrics Along with the package name, module name, class name, and function (or method) name, the tool provides the following code quality metrics for each method/function: LOC: Lines of code CC: Cyclomatic complexity PC: Parameter count Supported code smells Design smells The tool supports detection of the following design smells: Multifaceted abstraction: This smell arises when an abstraction has more than one responsibility assigned to it. Insufficient modularization: This smell arises when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both. Broken modularization: This smell arises when members of an abstraction are broken and spread across multiple abstractions. Hub-like modularization: This smell arises when a class-level abstraction has dependencies with a large number of other class-level abstractions (high incoming as well as outgoing dependencies). Broken hierarchy: This smell arises when a supertype and its subtype conceptually do not share an “IS-A” relationship, resulting in broken substitutability. Wide hierarchy: This smell arises when an inheritance hierarchy is “too” wide and shallow, indicating that intermediate types may be missing. Deep hierarchy: This smell arises when an inheritance hierarchy is excessively deep. Rebellious hierarchy: This smell arises when a subtype rejects the methods provided by its supertype(s). Some of the above smells, specifically multifaceted abstraction, insufficient modularization, hub-like modularization, and broken modularization, are also identified at the module level. Implementation smells The tool supports detection of the following implementation smells: Complex conditional: A complex conditional statement. Complex method: A method with high cyclomatic complexity. Empty catch block: A catch block of an exception is empty. Long identifier: An identifier with excessive length. Long method: A method is excessively long. Long parameter list: A method has a long parameter list. Long statement: An excessively long statement. Magic number: An unexplained number is used in an expression. Missing default: A switch statement does not contain a default case. Long lambda function: A long lambda function. Long message chain: A large chain-like access to attributes of an object.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction machine sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.

score de la tête « metaresearch » (Codex)0,003
score de la tête « metaresearch » (Gemma)0,013
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Logiciel · Signal consensuel: Logiciel
Score de désaccord entre enseignants0,036
Score d'incertitude au seuil0,120

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0030,013
Méta-épidémiologie (sens strict)0,0020,002
Méta-épidémiologie (sens large)0,0010,002
Bibliométrie0,0050,002
Études des sciences et des technologies0,0010,001
Communication savante0,0030,005
Science ouverte0,0030,005
Intégrité de la recherche0,0010,003
Charge utile insuffisante (le modèle a refusé de juger)0,0360,030

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,021
Tête enseignante GPT0,263
Écart entre enseignants0,242 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeSans objet
Domainenon disponible
GenreLogiciel

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2024
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueZenodo (CERN European Organization for Nuclear Research)Même sujetForensic and Genetic ResearchTravaux en français237 207