Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
45
datasets available to search
ShareScore release 0.7.1
Dataset results
45 results for “refactoring”
Speculative Automated Refactoring of Imperative Deep Learning Programs to Graph Execution
<p>Efficiency is essential to support ever-growing datasets, especially for Deep Learning (DL) systems. DL frameworks have traditionally embraced deferred execution-style DL code---supporting symbolic, graph-based Deep Neural Network (DNN) computation. While scalable, such development is error-prone, non-intuitive, and difficult to debug. Consequently, more natural, imperative DL frameworks encouraging eager execution have emerged but at the expense of run-time performance. Though hybrid approaches aim for the "best of both worlds," using them effectively requires subtle considerations. Our key insight is that, while DL programs typically execute sequentially, hybridizing imperative DL code resembles parallelizing sequential code in traditional systems. Inspired by this, we present an automated refactoring approach that assists developers in determining which otherwise eagerly-executed imperative DL functions could be effectively and efficiently executed as graphs. The approach features novel static imperative tensor and side-effect analyses for Python. Due to its inherent dynamism, analyzing Python may be unsound; however, the conservative approach leverages a speculative (keyword-based) analysis for resolving difficult cases that informs developers of any assumptions made. The approach is: (i) implemented as a plug-in to the PyDev Eclipse IDE that integrates the WALA Ariadne analysis framework and (ii) evaluated on nineteen DL projects consisting of 132 KLOC. The results show that 326 of 766 candidate functions (42.56%) were refactorable, and an average relative speedup of 2.16x on performance tests was observed with negligible differences in model accuracy. The results indicate that the approach is useful in optimizing imperative DL code to its full potential.</p>
Dataset for Automatic Refactoring Candidate Identification Leveraging Effective Code Representation
<p>The dataset consists of positive and negative case methods for Extract Method refactoring for selected GitHub repositories.<br> <br> <em>Each sample format - </em></p> <pre><code class="language-json">{ "repo_name": "...", "repo_url": "...", "positive_case_methods": ["...", "...", ...], "negative_case_methods": ["...", "...", ...] }</code></pre> <p> </p>
Model-driven Application Refactoring to Minimize Deployment Costs in Preemptible Cloud Resources
<p>1. Attached files: </p> <p>This archive contains 1440 MATLAB files, each one containing the results of a single experiment.<br /> The name of each file follows the following format:</p> <p> A_B_C_null_D_0.95_E_F.mat</p> <p>Where the fields A, B, C, D, E, and F are described as follows.</p> <p>A: number of users.<br /> Considered values are: 2500, 5000, 10000, 20000, 40000.</p> <p>B: variation in the profile of the requests.<br /> Considered values are: ref, var1, var2, var3, var4, var5.<br /> ref -> reference experiment, no users are halved or doubled<br /> var1 -> users in class 1 halved, other users doubled <br /> var2 -> users in class 2 halved, other users doubled <br /> var3 -> users in class 3 halved, other users doubled <br /> var4 -> users in class 4 halved, other users doubled <br /> var5 -> users in class 5 halved, other users doubled </p> <p>C: variation of the replaceability set of the application server.<br /> Considered values are: ref, k1, k2, k3, k4, k5.<br /> ref -> reference experiment, no rates are halved or doubled<br /> k1 -> only possible substitution has rate k1 halved and other rates doubled<br /> k2 -> only possible substitution has rate k2 halved and other rates doubled <br /> k3 -> only possible substitution has rate k3 halved and other rates doubled <br /> k4 -> only possible substitution has rate k4 halved and other rates doubled <br /> k5 -> only possible substitution has rate k5 halved and other rates doubled </p> <p>D: variation of the design constraints.<br /> Considered values are: none, 4, 34, 234.<br /> none -> no components can be replicated<br /> 4 -> only the application server can be replicated<br /> 34 -> only the application server and the database server can be replicated<br /> 234 -> all the components can be replicated</p> <p>E: Optimization algorithm.<br /> Considered values are: norefactoring, replacement, reassignment, full<br /> norefactoring -> experiment with no refactorings<br /> replacement -> experiment with only replacement refactoring<br /> reassignment -> experiment with only reassignment refactoring<br /> full -> experiment with replacement and reassignment refactorings</p> <p>F: Experiment seed.<br /> Considered values are from 1 to 20</p> <p> </p> <p>2. Data format:</p> <p>MATLAB data format, can be loaded from MATLAB using the following command:</p> <p>results = load(filename);</p> <p>results is defined as a structure with the following fields:</p> <p>results.cost<br /> Type: scalar, positive real number.<br /> Desc: hourly cost in US dollars.</p> <p> <br /> results.time<br /> Type: scalar, positive real number.<br /> Desc: total time (in seconds) needed by the algorithm to compute the solution.</p> <p>results.evaluations<br /> Type: scalar, positive integer number.<br /> Desc: number of constraints evaluations needed by the algorithm to compute the <br /> solution.</p> <p><br /> results.d<br /> Type: matrix, non negative positive real number. <br /> Desc: association matrix between rented resources (columns) and application <br /> components (rows). The sum of all the elements of this matrix is equal to<br /> the ECUs used by the application.</p>
Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring
<p>This is the dataset that accompanies the study: "<strong>Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring</strong>." This study has been accepted for publication at the 2022 Mining Software Repositories Conference.</p> <p><strong><em>Following is the abstract of the study:</em></strong></p> <p>To meet project timelines or budget constraints, developers intentionally deviate from writing optimal code to feasible code in what is known as incurring \textit{Technical Debt} (TD). Furthermore, as part of planning their correction, developers document these deficiencies as comments in the code (i.e., self-admitted technical debt or SATD). As a means of improving source code quality, developers often apply a series of refactoring operations to their codebase. In this study, we explore developers repaying this debt through refactoring operations by examining occurrences of SATD removal in the code of 76 open-source Java systems. Our findings show that TD payment usually occurs with refactoring activities and developers refactor their code to remove TD for specific reasons. We envision our findings supporting vendors in providing tools to better support developers in the automatic repayment of technical debt.</p> <p> </p>
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
<p>Streaming APIs are becoming more pervasive in mainstream Object-Oriented programming languages. For example, the Stream API introduced in Java 8 allows for functional-like, MapReduce-style operations in processing both finite and infinite data structures. However, using this API efficiently involves subtle considerations like determining when it is best for stream operations to run in parallel, when running operations in parallel can be less efficient, and when it is safe to run in parallel due to possible lambda expression side-effects. In this paper, we present an automated refactoring approach that assists developers in writing efficient stream code in a semantics-preserving fashion. The approach, based on a novel data ordering and typestate analysis, consists of preconditions for automatically determining when it is safe and possibly advantageous to convert sequential streams to parallel and unorder or de-parallelize already parallel streams. The approach was implemented as a plug-in to the Eclipse IDE, uses the WALA and SAFE analysis frameworks, and was evaluated on 11 Java projects consisting of ~642 thousand lines of code. We found that 36.31% of candidate streams were refactorable, and an average speedup of 3.49 on performance tests was observed. The results indicate that the approach is useful in optimizing stream code to their full potential.</p>
Subject source code for Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
<p>The set of open source Java projects packaged as Eclipse projects used for assessing our refactoring. Please refer to the included README.md file for building instructions and the LICENSE.md file for licensing information.<br> </p>
How Do I Refactor This? An Empirical Study on Refactoring Trends and Topics in Stack Overflow
<p>This is the dataset that accompanies the study: "<strong>How Do I Refactor This? An Empirical Study on Refactoring Trends and Topics in Stack Overflow</strong>." This study has been accepted for publication in the software engineering journal Empirical Software Engineering.</p> <p> </p> <p><strong><em>Following is the abstract of the study:</em></strong></p> <p>An essential part of software maintenance and evolution, refactoring is performed by developers, regardless of technology or domain, to improve the internal quality of the system, and reduce its technical debt. However, choosing the appropriate refactoring strategy is not always straightforward, resulting in developers seeking assistance. Although research in refactoring is well-established, with several studies altering between the detection of refactoring opportunities and the recommendation of appropriate code changes, little is known about their adoption in practice. Analyzing the perception of developers is critical to understand better what developers consider to be problematic in their code and how they handle it. Additionally, there is a need for bridging the gap between refactoring, as research, and its adoption in practice, by extracting common refactoring intents that are more suitable for what developers face in reality. In this study, we analyze refactoring discussions on Stack Overflow through a series of quantitative and qualitative experiments. Our results show that Stack Overflow is utilized by a diverse set of developers for refactoring assistance for a variety of technologies. Our observations show five areas that developers typically require help with refactoring-- Code Optimization, Tools and IDEs, Architecture and Design Patterns, Unit Testing, and Database. We envision our findings better bridge the support between traditional (or academic) aspects of refactoring and their real-world applicability, including better tool support.</p> <p><strong>Manuscript DOI:</strong> <a href="https://doi.org/10.1007/s10664-021-10045-x">https://doi.org/10.1007/s10664-021-10045-x</a> </p>
On the Relationship between Refactoring Actions and Bugs: A Differentiated Replication -- Replication Package
<p>This dataset contains working data sets and analysis scripts for the paper "On the Relationship between Refactorings and Bugs: A Differentiated Replication" by Massimiliano Di Penta, Gabriele Bavota, and Fiorella Zampetti, published at the ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2020).</p>
Refactoring Test Smells: A Perspective from Open-Source Developers
<p>Presentation video for the <strong>5th Brazilian Symposium on Systematic and Automated Software Testing (SAST)</strong>, during the <strong>11th Brazilian Conference on Software: Practice and Theory (CBSoft 2020)</strong></p>
Analyzing the Impact of Refactoring on Bad Smells
<p>Refactoring aims to remove bad smells and increase software maintainability by improving the software structure without changing its behavior. However, some studies show that refactoring tools may introduce new bad smells into the source code, but to the best of our knowledge, we have not been able to find a complete catalog that states the bad smells introduced from refactoring. To bridge this gap, this paper goal is to evaluate the impacts of refactoring on the detection of bad smells in open-source Java systems. Hence, we want to know if and when the automated refactoring removes or introduces bad smells. </p>
RAIDE: a tool for Assertion Roulette and Duplicate Assert identification and refactoring
<p>Video presentation of the article entitled "RAIDE: a tool for Assertion Roulette and Duplicate Assert identification and refactoring" of the 34th Brazilian Symposium on Software Engineering (SBES’20).</p>
Extending Refactoring Detection to Kotlin: A Dataset and Comparative Study
<p><span>This page serves as supplementary material for the article </span><span>Extending Refactoring Detection to Kotlin: A Dataset and Comparative Study</span><span>. In detail, we offer a downloadable dataset in JSON format, comprising 2,043 instances of refactoring instances covering 21 distinct refactoring types. These refactorings are applied within 200 commits across 10 Kotlin repositories and are manually validated by the authors of the paper.</span><span> </span></p> <p><span>Results.json: The results as </span><span>a single</span><span> JSON file.</span></p> <ul> <li> <p><span>Overview of JSON Template: Each entry in this file provides details </span><span>about</span><span> commits, including </span><span>their </span><span>SHA-1 hash, GitHub URL, and an exhaustive list of refactorings </span><span>identified</span><span> </span><span>in </span><span>that specific commit. Refactorings are defined by their type (e.g., 'RenameClass') and are accompanied by detailed descriptions of the </span><span>refactoring</span><span>. Additionally, the entry specifies the tools that </span><span>detected</span><span> the refactoring, such as 'RefDetect' and 'KotlinRMiner.' The validation field indicates whether the refactoring was confirmed, using 'TP' for true positive and 'FP' for false positive. Optional comments and validator information may be also included</span><span>.</span></p> </li> </ul> <p><span>AllCommits.zip: The Results for each repository in a single JSON file.</span></p> <p><span>Times.xlsx: The Excel file containing the time taken by each tool (RefDetect and KotlinMiner) to identify refactoring in each commit.</span></p> <p><span>Results.xlsx: T</span><span>he Excel file contains precision, recall, and F-score metrics for all identified refactoring types.</span></p>
Surpassing Threshold Barriers: Evaluating the Efficacy of Nature-Inspired Algorithms in Detecting Applied Refactorings
<p>This page is provided as supplementary material for the article: Surpassing Threshold Barriers: Evaluating the Efficacy of Nature-Inspired Algorithms in Detecting Applied Refactorings. More specifically, we provide the results, the refactorings detected by each tool, as a downloadable JSON file. </p> <p>Results.json: You can access the results comparing ACA with RefDetect, RefactoringMiner, NSGA-II, and the Greedy algorithm.</p> <ul> <li>Overview of JSON Template: Each entry in this file provides details about commits, including their SHA-1 hash, GitHub URL, and an exhaustive list of refactorings identified in that specific commit. Refactorings are defined by their type (e.g., 'RenameClass') and are accompanied by detailed descriptions of the refactoring. Additionally, the entry specifies the tools that detected the refactoring, such as 'ACA' and 'RefactoringMiner.' The validation field indicates whether the refactoring was confirmed, using 'TP' for true positive and 'FP' for false positive. Optional comment information may be also included.</li> </ul> <p>Times.xlsx: The Excel file containing the time taken by each tool to identify refactoring in each commit.</p> <p>Results.xlsx: The Excel file contains precision, recall, and F-score metrics for all identified refactoring types.</p>
Refactoring Dataset for SOEN 6491 Software Refactoring, Winter 2024 - Team Alpha
<p>The dataset collected by Team Alpha in SOEN 6491 Software Refactoring course, Winter 2024</p> <p><strong>Content Description</strong></p> <table> <tbody> <tr> <td><strong>File name</strong></td> <td><strong>File type</strong></td> <td><strong>Description</strong></td> </tr> <tr> <td>vertx.db, spring-boot.db, mina-sshd.db, guava.db</td> <td>SQLite Database</td> <td> <p>Fully collected refactoring dataset:</p> <ul> <li>Refactoring data (via RefactoringMiner)</li> <li>Code smells (via Organic)</li> <li>Code duplications (via PMD)</li> <li>Code churn (via Git)</li> <li>Timeline and statistics of releases in relation to refactoring commits. Releases are collected via GitHub API.</li> </ul> </td> </tr> <tr> <td>flink.db, rocketmq.db, ant.db, dubbo.db, elasticsearch.db, neo4j.db, rxjava.db, zookeeper.db</td> <td>SQLite Database</td> <td> <p>Partially collected refactoring dataset:</p> <ul> <li>Refactoring data (via RefactoringMiner)</li> </ul> </td> </tr> </tbody> </table>
Appendix of "Impact of Change Granularity in Refactoring Detection"
<p>This is the dataset for ICPC 2022 Impact of Change Granularity in Refactoring Detection, which contains data about coarse-grained refactorings in 19 open source repositories.</p> <p>There are 19 csv files in this dataset. Each of the csv contains 8 rows:</p> <p>1. repository: repository name <br> 2. commit(s): commit SHA-1 hash<br> 3. detected_refactoring_type: refactoring type detected in that commit<br> 4. description: description for that refactoring<br> 5. leftSideLocations: refactoring start place<br> 6. rightSideLocations: refactoring end place<br> 7. is_effective: whether this refactoring is a coarse-grained refactoring (null for refactoring whose coarse-granularity is equal to 1)<br> 8. granularity: coarse-granularity of this refactoring</p> <p>Note that refactorings detected using RefactoringMiner(2.2) with invalid locations has been excluded.</p>
Predicting Software Refactoring - joblib models
<p>Zip file contains Machine Learning models trained as a partial result of our work described in our paper</p>
Reproduction Package for "Preventing Refactoring Attacks on Software Plagiarism Detection through Graph-Based Structural Normalization"
<p>This repository stores all data used in the evaluation of the master's thesis "Preventing Refactoring Attacks on Software Plagiarism Detection through Graph-Based Structural Normalization". It ensures the continuous reproducibility of the results of the thesis.</p> <p>Content:</p> <ul> <li>JPlag v5.1.0 including the Java CPG frontend <ul> <li>Code base</li> <li>Runnable JAR</li> </ul> </li> <li>Data sets used for evaluation</li> <li>Evaluation results</li> <li>R script used to process the results</li> <li>Graphics and tables generated from the results</li> </ul> <p>The data sets were generated by Nils Niehues and Moritz Brödel and were originally published here:</p> <ul> <li><a href="../records/10430322">Supplementary Material for "Detecting Automatic Software Plagiarism via Token Sequence Normalization" (zenodo.org)</a></li> <li><a href="../records/10149536">Reproduction package for: Intelligent Match Merging to Prevent Obfuscation Attacks on Software Plagiarism Detectors (zenodo.org)</a></li> </ul> <p>The data sets are based partly on PROGPedia, available here:</p> <ul> <li><a href="../records/7449056">PROGpedia (zenodo.org)</a></li> </ul> <p>Visit <a title="State-of-the-Art Software Plagiarism & Collusion Detection" href="jplag.github.io/JPlag/" target="_blank" rel="noopener">JPlag</a> on GitHub for the current version.<br>See the thesis document for more information.</p> <p>Read about similar publications about Plagiarism Detection <a title="JPlag" href="https://jplag.github.io/MinimalLandingPage/" target="_blank" rel="noopener">here</a>.</p>
The Full Results and Dataset of Research of Refactoring Volatility
<p>This database is available duplication of the submmitted paper.The details are described below to facilitate replication of the experiment:</p> <ul> <li>Refactoring dataset.zip is a refactoring dataset of 48 projects, stored in json format, including the specific data of 807651 refactoring instances. The shared data can be provided for other research to further expand based on this data.</li> <li>oddsRatioResults.csv is the complete result of RQ1, including odd ratios and p values for 90 refactoring types.</li> <li>Rq2-datacollecting.py is a Python script used in RQ2 to collect different metrics, including metrics for the churn/history/experience dimension.</li> <li>sampling_result.json is a sample data set used in RQ4 to analyze the cause of refactoring volatility.</li> <li>RQ4 - Reasons explaination(Pictures).zip is the specific examples for different reasons for refactoring volatility, including a screenshot of the refactoring code changes at commits.</li> </ul>
Replication Package for MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability
<div> <div>This is the replication package for <em>MORCoRA: Multi-Objective Refactoring Recommendation Considering Review Availability</em></div> <br><br> <div> <p><strong>Refactoring sequences searched by MORCoRA</strong></p> </div> <div>The 6 directories contain the refactoring sequences searched by MORCoRA.</div> <div>The name of each directory is the name of the repository introduced in <em>Table 2. Dataset</em>.</div> <br> <div>Each directory includes 6 CSV files.</div> <div>The name of the CSV file represents the search algorithm used to search refactoring sequences.</div> <br> <div>Note that <em>NsgaiiN</em> represents using the NSGA-II algorithm without considering the review availability objective, which is the RA- in <em>Section 4.5</em>.</div> <br> <div>In each CSV file, a single row is the refactoring sequences searched and the recommended reviewers for it. The sequence with no appropriate reviewers will be noted as <em>No appropriate expertise reviewer</em>.</div> <br><br> <div>In each CSV file, a row consists of multiple columns, the last column represents the recommended reviewer, and the rest columns represent elements in the refactoring sequences.</div> <div>Each element consists of:</div> <div> <ul> <li>ROType: refactoring operation type</li> </ul> </div> <div> <ul> <li>class1info: <em>class1</em> in the <em>Table 1. Refactoring Operations</em> in the paper. It is the information of the source class where the number before <em>#</em> represents the access modifiers according to <a href="https://docs.oracle.com/javase/7/docs/api/constant-values.html#java.lang.reflect.Modifier.PROTECTED">modifiers and their corresponding int values</a>, the name after <em>#</em> represents the name for the class</li> </ul> </div> <div> <ul> <li>class1path: the path to the file containing the class</li> </ul> </div> <div> <ul> <li>class2info: <em>class2</em> in the <em>Table 1. Refactoring Operations</em> the formation of the target class</li> </ul> </div> <div> <ul> <li>class2path: the path to the file containing the class</li> </ul> </div> <div> <ul> <li>target: it can be "class" or "method" or "field" according to the refactoring type. The number before <em>#</em> represents the access modifier. The name after <em>#</em> is the name of the "class" or "method" or "field", and its type is revealed after the <em>@</em> symbol.</li> </ul> </div> <br><br> <div><strong>Manually review results</strong></div> <div>The manual review results of the 60 solutions introduced in <em>Section 4.3</em> is recorded in the <em>manually_review_60_solutions.csv</em></div> <br> <div>It includes 6 columns:</div> <div> <ul> <li>Repository: The name of the repository.</li> </ul> </div> <div> <ul> <li>Recommended Refactoring Operations: the searched refactoring sequence.</li> </ul> </div> <div> <ul> <li>Recommended Reviewer: the reviewer recommended to review the refactoring sequence.</li> </ul> </div> <div> <ul> <li>Reviewable: If no appropriate expertise reviewer is found for the sequence, the value is "0", otherwise "1".</li> </ul> </div> <div> <ul> <li>Code smell Eliminated: The code smell type detected by JDeodorant that the recommended refactoring can eliminate. If the refactoring sequence cannot eliminate any code smell, then it is "No".</li> </ul> </div> <div> <ul> <li>Valid: If the refactoring sequence is recommended with appropriate reviewer (value in the column "Reviewable" is "1") and meaningful, and eliminates at least one code smell, the value is "1", otherwise "0".</li> </ul> </div> </div>
Microservices Refactoring Tools - Paper Appendix
<p>This data set contains the rapid review results and tool inspection details for the study "Tools for Refactoring to Microservices:<br> A Preliminary Usability Report" </p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.