April 2020 – SE metrics (Software Engineering)

Generating comments in code – can a machine make our code more readable?

Our research team has been working with code comments for a while now. We have done analyses of source code comments and the code that is commented. We have also worked with the needs for code comments.

The results showed that AI support for code reviewing process is very much needed. However, it has also shown that the current tools are not good enough yet. One of the tools is DeepCode.ai, which analyzes code repository and finds problems in the code. It is a great tool, but it has been trained on large data sets from open source projects, which makes it tricky to use on proprietary software. It does not know how to capture the project specific characteristics.

I’ve recently cam across this article (https://link-springer-com.ezproxy.ub.gu.se/content/pdf/10.1007/s10664-019-09730-9.pdf) which is about generating code comments. It can generate code comments (not review comments) for the Java programming language. It “understands” what the code does and generates a natural language description of the code. The tool is based on the latest work from the NLP domain and has been trained on over 44 million statements, which is quite a number😊

The tool is not perfect (yet), but shows improvement over existing approaches and is definitely opening up new alleys of using NLP in Software Engineering.

Let’s stay tuned, more will come!

Quality of Deep Learning code – article review

A (deep) Staircase in Vatican, Image by JEROME CLARYSSE from Pixabay

http://swat.polymtl.ca/~foutsekh/docs/hadhemi-MSR2020.pdf

Deep learning models are often designed, trained and tested in Python. It is a language with a nice structure, quite straigtforward syntax and a lot of libraries. However, very few tutorials about deep learning (or any Python programming tutorials) discuss the quality of the code, e.g. its modularization, encapsulation, naming consistency.

As a result, a lot of code for machine learning, written in Python, often is hard to read and hard to grasp. Even if used as part of jupyter notebooks, the code is not really commented (often).

The study behind the link above is a study that supports my long gut feeling about this. The findings show that (from the abstract): First, long lambda expression, long ternary conditional expression, and complex container comprehension smells are frequently found in deep learning projects. That is, deep learning code involves more complex or longer expressions than the traditional code does. Second, the number of code smells increases across the releases of deep learning applications. Third, we found that there is a co-existence between code smells and software bugs in the studied deep learning code, which confirms our conjecture on the degraded code quality of deep learning applications.

The second finding, about the constant increase of the number of code smells, is similar to the studies we did in proprietary software about complexity – the complexity “never” decreases ( http://web.student.chalmers.se/~vard/files/Monitoring%20Complexity%20Evolution.pdf ).

The study compares 59 deep learning systems with 59 non-ML systems from GitHub. One could argue that the sample is not representative (no propprietary systems), but it is a fair sample.

To sum up, a very nice reading, showing that we need to think about quality, not only models, but also code quality.

How bugs are born: a model to identify how bugs are introduced in software components (review)

https://link-springer-com.ezproxy.ub.gu.se/content/pdf/10.1007/s10664-019-09781-y.pdf

I’ve came across this article from Empirical Software Engineering and it cought my attention. It describes a study of how to identify where a bug was introduced.

The article accurately observes that the defects are fixed, most often, in a place where they were NOT introduced. So, the question is whether we can find where the defects were introduced.

Several studies focused on understanding which release/commit introduced a specific defect. This article describes how to find this particular release. It is based on a theoretical framework of perfect tests, i.e. tests which can capture defects in releases where they were introduced. The authors of this study evaluate four different algorithms on two different open source projects. Their findings show that it is possible, to some extent, find the right release where the bug was introduced. Knowing the release and knowing which changes were introduced into the release, it is possible to narrow down the piece of code that contains the bug.

Very interesting work and looking forward to more studies in this area, in particular in the area of proprietary software!

Finding many needles in one haystack?

Image by S. Hermann & F. Richter from Pixabay

Multiple fault localization: https://www.sciencedirect.com/science/article/pii/S0950584920300641?dgcid=coauthor

A lot of defect research is focused on either localization of defects or the prediction whether a defect will be found/fixed, etc. I’m guilty to adding to the state of the art in this area with a number of articles. It’s a great line of work, nice because we can play with data and get results that can actually be verified – we can check whether a defect is or is not there.

However, in many cases, the defect can be a mistake made in a number of places – so-called a multiple fault or multiple faults. Therefore, this article, freshly from the press of IST, caught my attention. It presents a systematic review of what has been done in that area.

Turns out, not that much, but the field has been gaining popularity in the past few years.

What I like, in particular, about this paper is the fact that it asks a question about which datasets exist (see Table 8 in the paper for the full reference). I can’t wait to take a closer look at these datasets – maybe something for me PhD course in metrics next year?

Machine learning testing.. (review)

https://ieeexplore.ieee.org/abstract/document/9000651

Image by DarkWorkX from Pixabay

Testing of machine learning systems is a tricky business. Not only the algorithms are based on statistics, they are also very complex and they are highly dependent on the data that is used for training and validation. Yet, the algorithms are very important for our modern software systems and therefore we need to make sure that they work as they are intended to.

I’ve came across an article where authors reviewed literature on how machine learning systems are tested. A list of aspects that this paper looks into is:

What to test:

Test input generation
Test oracle generation
Test adequacy evaluation
Bug report analysis
Debug and repair

Where to test:

Data testing
Learning program testing
Framework testing

Test for what:

Correctness
Model Relevance
Robustness&Security
Efficiency
Fairness
Interpretability
Privacy

The list is quite impressing and so is the paper. For me, the most interesting category was the testing of data, which reviews challenges and also provides some solutions. For example, it lists frameworks which are used for testing of data: ActiveClean or BoostClean. These frameworks look at the data and try to capture how valuable the data is for the actual algorithm.