Tools, processes and factors influencing of code review

Code review is the most effective quality assurance strategy in software development where reviewers aim to identify defects and improve the quality of source code of both commercial and open-source software. Ultimately, the main purpose of code review activities is to produce better software products. Review comments are the building blocks of code review. There are many approaches to conduct reviews and analysis source code such as pair programming, informal inspections, and formal inspections. Reviewers are responsible for providing comments and suggestions to improve the quality of the proposed source code modifications. This work aims to succinctly describe code review process, giving a framework of the tools and factors influencing code review to aid reviewers and authors in the code review stages and choose the suitable code review tool

Lab Package: Static Code Analysis

Antud bakalaureusetöö eesmärgiks on luua uus versioon staatilist koodianalüüsi tutvustavast praktikumimaterjalist, mida kasutatakse Tartu Ülikoolis aines “Tarkvara Testimine (MTAT.03.159)”. Töös kirjeldatakse nii peamisi põhjuseid muutusteks kui ka töö käigus valminud uuenenud materjale. Loodud materjale rakendati eelnimetatud aines ning neile antud tagasiside oli positiivne. Töö lõpeb tudengite antud tagasiside analüüsiga ning lisatud on ka soovitusi edasisteks parandusteks.The main goal of this thesis is to enhance the lab materials about static code analysis used in the course “Software Testing (MTAT.03.159)” in the University of Tartu. The motivation for the changes is explained and the new materials are introduced in this work. The materials were applied in the course and received positive feedback. Students’ feedback given after the execution of the lab is analyzed with suggestions for future improvements given

Would static analysis tools help developers with code reviews?

Code reviews have been conducted since decades in software projects, with the aim of improving code quality from many different points of view. During code reviews, developers are supported by checklists, coding standards and, possibly, by various kinds of static analysis tools. This paper investigates whether warnings highlighted by static analysis tools are taken care of during code reviews and, whether there are kinds of warnings that tend to be removed more than others. Results of a study conducted by mining the Gerrit repository of six Java open source projects indicate that the density of warnings only slightly vary after each review. The overall percentage of warnings removed during reviews is slightly higher than what previous studies found for the overall project evolution history. However, when looking (quantitatively and qualitatively) at specific categories of warnings, we found that during code reviews developers focus on certain kinds of problems. For such categories of warnings the removal percentage tend to be very high, often above 50% and sometimes up to 100%. Examples of those are warnings in the imports, regular expressions, and type resolution categories. In conclusion, while a broad warning detection might produce way too many false positives, enforcing the removal of certain warnings prior to the patch submission could reduce the amount of effort provided during the code review process