Security‐based code smell definition, detection, and impact quantification in Android

• Published in: Software, practice & experience Vol. 53; no. 11; pp. 2296 - 2321
• Main Authors: Zhong, Yi, Shi, Mengyu, He, Jiawei, Fang, Chunrong, Chen, Zhenyu
• Format: Journal Article
• Language: English
• Published: Bognor Regis Wiley Subscription Services, Inc 01-11-2023
• Subjects: Priorities; Quality assurance; Security; Source code
• ISSN: 0038-0644; 1097-024X
• DOI: 10.1002/spe.3257

Android's high market share and extensive functionality make its security a significant concern. Research reveals that many security issues are caused by insecure coding practices. As a poor design indicator, code smell threatens the safety and quality assurance of Android applications (apps). Although previous works revealed specific problems associated with code smells, the field still lacks research reflecting Android features. Moreover, the cost and time limit developers to repairing numerous smells timely. We conducted a study, including Def inition, D etection, and I mpact Q uantification for Android code smell (DefDIQ): (1) define 15 novel code smells in Android from a security programming perspective and provide suggestions on how to eliminate or mitigate them; (2) implement DACS (Detect Android Code Smell) to automatically detect the custom code smells based on ASTs; (3) investigate the correlation between individual smells with DACS detection results, select suitable code smells to construct fault counting models, then quantify their impact on quality, and thereby generating code smell repair priorities. We conducted experiments on 4575 open‐source apps, and the findings are: (i) Lin's CCC between DACS and manual detection results reaches 0.9994, verifying the validity; (ii) the fault counting model constructed by zero‐inflated negative binomial is superior to negative binomial (AIC = 517.32, BIC = 522.12); some smells do indicate fault‐proneness, and we identify such avoidable poor designs; (iii) different code smells have different levels of importance and the repair priorities constructed provide a practical guideline for researchers and inexperienced developers.