The popularity of smart phones and mobile applications is growing every day. Every day, new or updated mobile applications are being submitted to different mobile stores. The rapidly increasing number of mobile applications has led to an increase in the interest in overall source code quality. Therefore, we will present a case study, where we analyzed different open source Android mobile applications from different domains and different sizes. They were analyzed using the SonarQube platform, based on the SQALE method. We were aiming to research the overall code quality, the connection between lines of code and technical depth and the most common issues facing mobile applications. The results show that the majority of applications tend to have similar code issues and potential difficulties when it comes to maintenance or updates. Additional Key Words and Phrases: source code quality, analysis, technical depth, SQALE In light of the popularity that smart phones and mobile applications have achieved, and intrigued by the constant increase in the number of mobile applications submitted to mobile stores (Statista, 2015), we raised the question of whether this trend has an impact on the overall quality of source code. We were concerned that many mobile application developers may have been focused mostly on fast builds and releases and neglected testing and good design practices, and that this could lead to further difficulties down the road with regard to maintenance and the long-term success of the applications. Two separate studies in the field of source quality in mobile applications (Syer, Nagappan, Adams, & Hassan, 2014) and (Pocatilu, 2006) have verified that using classical object oriented metrics and approaches for measuring the code quality of desktop and web applications can be used to measure the source code quality of mobile phone applications. A study performed at the University of Maribor (Jošt, Huber, & Hericko, 2013), dealt with a similar issue: two hypothesis were tested, of which the first -- which claimed that using object oriented metrics for the analysis of mobile application code quality does not deter from their usage for the source code quality of desktop applications -- was confirmed. However, the second hypothesis, which claimed that results from analyzing source code quality of equivalent mobile applications developed for different platforms would be undifferentiated, was rejected. The previously mentioned study (Syer, Nagappan, Adams, & Hassan, 2014), has also proven that classical relations between metrics, like “high coupling low cohesion,” which are eligible for the source code quality of desktop and web applications and are eligible for mobile applications as well. Their study also found that the claim that “more code, less quality” was true in 3 out of 5 applications.
Static code analysis is a technique for the evaluation of code quality that is performed by analyzing the
source code or the binary code, with no need of actually running the code
One of the key aspects that defines usable and good tools for static code analysis is that the
representation of the results has to be easy to read and understand by the developers
In this field, there are some relevant standards and methods that support the evaluation of software code
quality. ISO/IEC 9126 and its successor ISO/IEC 25010:2011 directly address the issue of system and
software quality. We have used ISO/IEC 9126 as a quality model for our analysis, which was performed
with SonarQube, based on the SQALE method
Software quality assessment, based on life cycle expectations (SQALE), is a method developed by DNV
ITGS France that is platform independent and is applicable to any kind of development methodology. The
SQALE method estimates the technical debt, which can be presented with custom units, such as cost in
money or the time required to remove all the found issues. One of the main four concepts is the quality
model, which is organized in three levels. The first and the second level present characteristics such as
testability, maintainability etc. and their related sub-characteristics. The third level defines the
nonfunctional requirements or simply the rules, which are usually dependent on the programming language
used. The analysis model defines the time required for fixing an issue determined by a rule
SonarQube is an open source platform that provides a central place for managing source code quality
for single or multiple projects. Its extension mechanism allows for the addition of new uncovered
Small Scale Analysis of Source Code Quality with regard to Native Android Mobile Applications
programming languages, tools and features that in conjunction with the default features and tools, such
as visual reporting and across projects, time machine etc. provides a genuinely flexible and powerful tool
for source code quality analysis
A case study is a suitable type of research methodology in the field of software engineering, because it studies contemporary phenomena in its natural context. Primarily, the case study was used for exploratory purposes, but nowadays it is also used for descriptive purposes. Case studies are by definition conducted in a real word environment, and thus have a high degree of realism (Runeson, Hostl 2008).
A case study usually combines five major process steps. The first is case study design, where objectives
are defined and a case study is planned. This phase is followed by preparation for data collection, which
includes definitions of procedures and protocols. The third step is collecting the evidence, and this is
followed by an analysis of the collected data. The final step is the reporting phase of the case study
The aim of our study was a comparison of the results obtained using the SQALE method with the help of the SonarQube platform, where we analyzed open source mobile applications. We addressed the following research questions:
RQ1: Is there a major deviation between the overall qualities of the mobile applications source code? RQ2; Do lines of code have a direct influence on the technical depth of the mobile applications? RQ3: What are the most common issues that occur in the analyzed mobile applications?
Our analysis was based on open source mobile applications, so we looked for applications in the F-Droid
repository
Our quality profile, in accordance with the SQALE quality model, was in compliance with all Android Lint
rules
After an analysis, the collected data was graded via the SQALE method. The results are presented in Figure 2. As can be seen, the applications are aligned based on lines of code (LOC). The overall result reveals technical depth and is presented in the number of days that are needed in order to remove all of the technical depth. We can see that the applications with the higher number of LOC have more technical depth, and that applications with less LOC effectively do not have technical depth. But in between, by observation, we cannot find a rule that applications with more lines of code have more technical depth.
Small Scale Analysis of Source Code Quality with regard to Native Android Mobile Applications • 2:13 60,000 50,000 aligned by LOCs ->
–is the index that represents the time required to eliminate the technical debt for 1000 lines of ℎ – is the time required to eliminate the technical debt in the application X.
– is the total number of lines of code (LOC) for the application X.
After applying the formula we get the results presented in Figure 4. The graph shows mobile applications aligned by LOC and time (in days) required to eliminate the technical debt for 1000 lines of code. From the obtained results, based on the data and the applied formula, we were able to see that 13.4% of mobile applications have reached a score that we can categorize as weak and was greater than the upper control limit, which in our case was 9.73 days. On the contrary, 16.6% of the applications received a score that was better than the lower control limit, which was 2.95 days. The average score was 6.79 days, which reveals that the applications had a fair share that can be improved. The upper control limit, lower control limit and mean were calculated based on the results obtained from the analysis. As can we see from the chart, both applications with large LOC and applications with small LOC scored similar scores, so we can conclude, that lines of code do not have a linear correlation with technical depth. 16.00 14.00 k9 l-tkgaaeuoooCB trcSaeeuhC trcxSTeeeu iledbnBA ludnooCw iircddooCVm iisahhdU llfaaw irzzgaaaeppo udoD itrrsaddno -trrrcaepo ryep trraeunnRB ckaabupdno irrssLceeudoBw lrFaaaphnpCm itrrcaadd trrrcaeho ftspw irLggnnnuo tceeunpnoDOm iltssyykb iiscaCAm iifrykaebdow irxTeduR ittrsaeePnno irsaenubm aligned by LOCs ->
We also searched for the most common issues that occur in analyzed mobile applications. The detected issues according to our quality profile, based on ISO/IEC 9126, were categorized. Shares were divided among the categories maintainability, changeability, reliability, security, portability, efficiency and testability. The data revealed that the most critical categories were maintainability and changeability, and roughly 91% of all detected issues were categorized in one of these categories. In addition to the mentioned categories, reliability also took a significant share. All shares of the detected issues are presented in the pie chart in Figure 5.
Reliability 9%
Maintainability Changability 44% 44% [IME KATEGORIJE]
[ODSTOTEK]
Small Scale Analysis of Source Code Quality with regard to Native Android Mobile Applications • 2:15
RQ1. The first question was aimed at finding if a major deviation occurred between the overall results of the analyzed mobile applications source code. As we can see in Figure 4, the score of 70% of the applications is within the control boundaries and lines of code do not have a direct impact on the overall score. This roughly gives an answer to our question. Another indicator that can support the claim that no major deviation occurs between the overall results are the results from Figure 5, which clearly show that the weakness detected throughout all of the applications belong to the same categories. We believe that this similarity could be due to the fact that most of the developers use IDEs that have code suggestions and validation tools, such as Android Lint, included in their default configuration.
RQ2. The research question was aimed at finding if lines of code in mobile applications have any significant influence on technical depth. We analyzed the applications and presented the technical depth of each mobile application in days. The data was then normalized using the presented formula in Figure 2. We took into consideration that the indexes were within tolerable boundaries and that in most cases the applications had similar code quality. Based on this, the graph in Figure 4 shows that there is no visible correlation between lines of code and technical depth in the analyzed mobile applications. RQ3. The last question was aimed at finding the most common issues that occurred in analyzed mobile applications. From the 237 rules that we analyzed with our code, we detected only 79. This violations actually represent the 3rd level of the SQALE quality model. In order to get a clear answer to the presented research question, we represented the data with a bar chart. The most commonly detected issue, with a nearly 25% occurrence, was the visibility modifier, followed by other issues such as: avoidance of commented out-lines of code, magic number should not be used, unused private methods and others. All issues, and their respective shares, are presented in Figure 5.
25.00% 20.00% 15.00% 10.00% 5.00% 0.00% Even though we were concerned that code quality would suffer due to the rapid development and race for a share of the growing market, our analysis has given us a results that were not as critical as we expected. In our opinion, there is lot of room for improvement, but the current state of things is bearable and in our subjective opinion is only going to get better, mostly because trends show that the industry is more and more concerned with code quality. This is leading to better quality in the product itself. This analysis has pointed to a few issues that constantly occur in every project. By dealing with this handful of problems, we could significantly decrease the number of detected issues and can lower the technical debt by more than 40%.
We would also like to share our experience of working with the open source platform SonarQube, and
would like to stress that it provided a pleasant experience. The platform itself is a powerful tool for
managing code quality and in our opinion this tool or similar tools