关键词标记的自我承认的技术债务和静态代码分析有显著的关系，但重叠有限

IF 1.7 3区计算机科学 Q3 COMPUTER SCIENCE, SOFTWARE ENGINEERING

Software Quality Journal Pub Date : 2023-11-16 DOI:10.1007/s11219-023-09655-z

Leevi Rantala, Mika Mäntylä, Valentina Lenarduzzi

{"title":"关键词标记的自我承认的技术债务和静态代码分析有显著的关系，但重叠有限","authors":"Leevi Rantala, Mika Mäntylä, Valentina Lenarduzzi","doi":"10.1007/s11219-023-09655-z","DOIUrl":null,"url":null,"abstract":"<p>Technical debt presents sub-optimal choices made in development, which are beneficial in the short term but not in the long run. Consciously admitted debt, which is marked with a keyword, e.g., TODO, is called keyword-labeled self-admitted technical debt (KL-SATD). KL-SATD can lead to adverse effects in software development, e.g., to a rise in complexity within the developed software. We investigated the relationship between KL-SATD from source code comments and reports from the highly popular industrial program analysis tool SonarQube. The goal was to find which SonarQube metrics and issues are related to KL-SATD introduction and removal and how many KL-SATD in the context of an issue addresses that issue. We performed a study with 33 software repositories. We analyzed the changes in SonarQube reports (sqale index, reliability and security remediation metrics, and SonarQube issues) and the relationship to KL-SATD addition and removal with mixed model analysis. We manually annotated a sample to investigate how many KL-SATD comments are in the context of SonarQube issues and how many address them directly. KL-SATD is associated with a reduction in code maintainability measured with SonarQube’s sqale index. KL-SATD removal is associated with an increase in code maintainability (sqale index) and reliability measured with SonarQube’s reliability remediation effort. The introduction and removal of KL-SATD have a predominantly relationship with code smells, and not with vulnerabilities and bugs. Manual annotation revealed that 36% of KL-SATD comments are in the context of a SonarQube issue, but only 15% of the comment address an issue. This means that despite of statistical relationship between KL-SATD comments and SonarQube reports there is a large set of KL-SATD comments that are in areas that Sonarqube reports as clean or free of maintainability issues. KL-SATD introduction and removal are connected mainly to code smells, connecting them to maintainability rather than reliability or security. This is reinforced by the relationship with the sqale index, as well as the dominance of code smells in SonarQube issues. Many KL-SATD issues have characteristics going beyond static analysis tools and require future studies extending the capabilities of the current tools. As KL-SATD comments and SonarQube reports appear to have limited overlap, it suggests that they are complementary and both are needed for getting a comprehensive view coverage of code maintainability. The study also presents rules violations developers should be aware of regarding KL-SATD introduction and removal.\n</p>","PeriodicalId":21827,"journal":{"name":"Software Quality Journal","volume":"235 1","pages":""},"PeriodicalIF":1.7000,"publicationDate":"2023-11-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"Keyword-labeled self-admitted technical debt and static code analysis have significant relationship but limited overlap\",\"authors\":\"Leevi Rantala, Mika Mäntylä, Valentina Lenarduzzi\",\"doi\":\"10.1007/s11219-023-09655-z\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"<p>Technical debt presents sub-optimal choices made in development, which are beneficial in the short term but not in the long run. Consciously admitted debt, which is marked with a keyword, e.g., TODO, is called keyword-labeled self-admitted technical debt (KL-SATD). KL-SATD can lead to adverse effects in software development, e.g., to a rise in complexity within the developed software. We investigated the relationship between KL-SATD from source code comments and reports from the highly popular industrial program analysis tool SonarQube. The goal was to find which SonarQube metrics and issues are related to KL-SATD introduction and removal and how many KL-SATD in the context of an issue addresses that issue. We performed a study with 33 software repositories. We analyzed the changes in SonarQube reports (sqale index, reliability and security remediation metrics, and SonarQube issues) and the relationship to KL-SATD addition and removal with mixed model analysis. We manually annotated a sample to investigate how many KL-SATD comments are in the context of SonarQube issues and how many address them directly. KL-SATD is associated with a reduction in code maintainability measured with SonarQube’s sqale index. KL-SATD removal is associated with an increase in code maintainability (sqale index) and reliability measured with SonarQube’s reliability remediation effort. The introduction and removal of KL-SATD have a predominantly relationship with code smells, and not with vulnerabilities and bugs. Manual annotation revealed that 36% of KL-SATD comments are in the context of a SonarQube issue, but only 15% of the comment address an issue. This means that despite of statistical relationship between KL-SATD comments and SonarQube reports there is a large set of KL-SATD comments that are in areas that Sonarqube reports as clean or free of maintainability issues. KL-SATD introduction and removal are connected mainly to code smells, connecting them to maintainability rather than reliability or security. This is reinforced by the relationship with the sqale index, as well as the dominance of code smells in SonarQube issues. Many KL-SATD issues have characteristics going beyond static analysis tools and require future studies extending the capabilities of the current tools. As KL-SATD comments and SonarQube reports appear to have limited overlap, it suggests that they are complementary and both are needed for getting a comprehensive view coverage of code maintainability. The study also presents rules violations developers should be aware of regarding KL-SATD introduction and removal.\\n</p>\",\"PeriodicalId\":21827,\"journal\":{\"name\":\"Software Quality Journal\",\"volume\":\"235 1\",\"pages\":\"\"},\"PeriodicalIF\":1.7000,\"publicationDate\":\"2023-11-16\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Software Quality Journal\",\"FirstCategoryId\":\"94\",\"ListUrlMain\":\"https://doi.org/10.1007/s11219-023-09655-z\",\"RegionNum\":3,\"RegionCategory\":\"计算机科学\",\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"Q3\",\"JCRName\":\"COMPUTER SCIENCE, SOFTWARE ENGINEERING\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Software Quality Journal","FirstCategoryId":"94","ListUrlMain":"https://doi.org/10.1007/s11219-023-09655-z","RegionNum":3,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"Q3","JCRName":"COMPUTER SCIENCE, SOFTWARE ENGINEERING","Score":null,"Total":0}

引用次数: 0

摘要

技术债务表示在开发过程中做出的次优选择，这些选择在短期内是有益的，但从长期来看却不是。用关键字(如TODO)标记的自觉承认的债务称为关键字标记的自我承认技术债务(KL-SATD)。KL-SATD会在软件开发中导致不利的影响，例如，在开发的软件中增加复杂性。我们调查了来自源代码注释的KL-SATD和来自非常流行的工业程序分析工具SonarQube的报告之间的关系。目标是找出哪些SonarQube指标和问题与KL-SATD的引入和移除有关，以及在一个问题的上下文中有多少KL-SATD可以解决该问题。我们对33个软件存储库进行了研究。我们使用混合模型分析分析了SonarQube报告中的变化(sqale指数、可靠性和安全性补救度量以及SonarQube问题)以及与KL-SATD添加和删除的关系。我们手动注释了一个示例，以调查在SonarQube问题的上下文中有多少KL-SATD注释，以及有多少注释直接解决了这些注释。KL-SATD与用SonarQube的sqale指数衡量的代码可维护性的降低有关。KL-SATD的移除与代码可维护性(平方指数)的增加以及SonarQube可靠性补救工作测量的可靠性有关。KL-SATD的引入和移除主要与代码气味有关，而与漏洞和bug无关。手动注释显示，36%的KL-SATD评论是在SonarQube问题的上下文中，但只有15%的评论是针对问题的。这意味着，尽管KL-SATD注释和SonarQube报告之间存在统计上的关系，但仍有大量KL-SATD注释位于SonarQube报告为干净或没有可维护性问题的区域。KL-SATD的引入和移除主要与代码气味有关，将它们与可维护性而不是可靠性或安全性联系起来。与sqale索引的关系以及SonarQube问题中代码气味的主导地位加强了这一点。许多KL-SATD问题的特点超出了静态分析工具的范围，需要未来的研究来扩展当前工具的功能。由于KL-SATD注释和SonarQube报告似乎有有限的重叠，这表明它们是互补的，并且对于获得代码可维护性的全面视图覆盖都是必需的。该研究还提出了开发人员在引入和删除KL-SATD时应该注意的违规规则。

本文章由计算机程序翻译，如有差异，请以英文原文为准。

Keyword-labeled self-admitted technical debt and static code analysis have significant relationship but limited overlap

查看原文本刊更多论文

Keyword-labeled self-admitted technical debt and static code analysis have significant relationship but limited overlap

Technical debt presents sub-optimal choices made in development, which are beneficial in the short term but not in the long run. Consciously admitted debt, which is marked with a keyword, e.g., TODO, is called keyword-labeled self-admitted technical debt (KL-SATD). KL-SATD can lead to adverse effects in software development, e.g., to a rise in complexity within the developed software. We investigated the relationship between KL-SATD from source code comments and reports from the highly popular industrial program analysis tool SonarQube. The goal was to find which SonarQube metrics and issues are related to KL-SATD introduction and removal and how many KL-SATD in the context of an issue addresses that issue. We performed a study with 33 software repositories. We analyzed the changes in SonarQube reports (sqale index, reliability and security remediation metrics, and SonarQube issues) and the relationship to KL-SATD addition and removal with mixed model analysis. We manually annotated a sample to investigate how many KL-SATD comments are in the context of SonarQube issues and how many address them directly. KL-SATD is associated with a reduction in code maintainability measured with SonarQube’s sqale index. KL-SATD removal is associated with an increase in code maintainability (sqale index) and reliability measured with SonarQube’s reliability remediation effort. The introduction and removal of KL-SATD have a predominantly relationship with code smells, and not with vulnerabilities and bugs. Manual annotation revealed that 36% of KL-SATD comments are in the context of a SonarQube issue, but only 15% of the comment address an issue. This means that despite of statistical relationship between KL-SATD comments and SonarQube reports there is a large set of KL-SATD comments that are in areas that Sonarqube reports as clean or free of maintainability issues. KL-SATD introduction and removal are connected mainly to code smells, connecting them to maintainability rather than reliability or security. This is reinforced by the relationship with the sqale index, as well as the dominance of code smells in SonarQube issues. Many KL-SATD issues have characteristics going beyond static analysis tools and require future studies extending the capabilities of the current tools. As KL-SATD comments and SonarQube reports appear to have limited overlap, it suggests that they are complementary and both are needed for getting a comprehensive view coverage of code maintainability. The study also presents rules violations developers should be aware of regarding KL-SATD introduction and removal.

求助全文

通过发布文献求助，成功后即可免费获取论文全文。去求助

来源期刊

Software Quality Journal 工程技术-计算机：软件工程

CiteScore

4.90

自引率

5.30%

发文量

审稿时长

>12 weeks

期刊介绍： The aims of the Software Quality Journal are: (1) To promote awareness of the crucial role of quality management in the effective construction of the software systems developed, used, and/or maintained by organizations in pursuit of their business objectives. (2) To provide a forum of the exchange of experiences and information on software quality management and the methods, tools and products used to measure and achieve it. (3) To provide a vehicle for the publication of academic papers related to all aspects of software quality. The Journal addresses all aspects of software quality from both a practical and an academic viewpoint. It invites contributions from practitioners and academics, as well as national and international policy and standard making bodies, and sets out to be the definitive international reference source for such information. The Journal will accept research, technique, case study, survey and tutorial submissions that address quality-related issues including, but not limited to: internal and external quality standards, management of quality within organizations, technical aspects of quality, quality aspects for product vendors, software measurement and metrics, software testing and other quality assurance techniques, total quality management and cultural aspects. Other technical issues with regard to software quality, including: data management, formal methods, safety critical applications, and CASE.