What this talk is about: Tools that help ensure code quality; SonarQube as a unified platform for quality control.

1. Integrated usage of analysers to
improve code quality
Yuri Minaev (PVS-Studio)

2. About me
2
• Yuri Minaev
• C++ developer at PVS-
Studio
• minaev@viva64.com

3. What this talk is about
• Tools that help ensure code quality
• SonarQube as a unified platform for quality control
3

4. Why we need this
• Any project will have bugs
• They are easier to fix before
they grow
• Automation is convenient
4

5. The cost to fix a defect
5

6. How to protect code from bugs
6

7. Code review
7

8. Code style
• Unification of style
• Readability
• Easier to debug
• Easier to find defects
8

9. Code style: example
void DoSomething(Things& things, bool remove) {
for (auto i = 0; i < things.Count(); ++i) {
things[i].DoWhatever();
if (remove) {things.Remove(i);
} else { things.ApplyChange(i); } }
}
9

10. Code style: example
void DoSomething(Things& things, bool remove)
{
for (auto i = 0; i < things.Count(); ++i)
{
things[i].DoWhatever();
if (remove)
things.Remove(i);
else
things.ApplyChange(i);
}
}
10

11. Static analysis
• It’s like code review, but is done automatically
• Works well with other methods
• Finds error patterns, which programmers don’t know
about
11

12. Code smells
• Code duplication
• Long functions
• Too many parameters
• God object
12

13. Code smells: example
class ManagerOfEverything
{
public:
void InitDatabase();
void UpdateDatabase();
int CalculateSomeImportantValue();
//…
void SendRequest(const RequestData& data);
void ReceiveRequest(RequestData& data);
//…
void CreateInputForm();
void FillInputForm(const FormData& data);
//…
void MakeMeACoffee();
};
13

14. Code smells != errors
• Even if your code smells, it
doesn’t mean it works
incorrectly
14

15. Code smells != errors, but...
• Such code is harder to debug
• As a rule, harder to read
• Harder to find bugs
• Harder to fix bugs
15

16. Dynamic analysis
• Debuggers
• Profilers
• Sanitisers
• Unit tests, to an extent
16

17. AddressSanitizer
17
#include <stdlib.h>
int main()
{
char* x = (char*)malloc(10 * sizeof(char*));
free(x);
return x[5];
}

18. AddressSanitizer
==9901==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5 at pc 0x45917b bp 0x7fff4490c700
sp 0x7fff4490c6f8
READ of size 1 at 0x60700000dfb5 thread T0
#0 0x45917a in main use-after-free.c:5
#1 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
#2 0x459074 in _start (a.out+0x459074)
0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000)
freed by thread T0 here:
#0 0x4441ee in __interceptor_free projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x45914a in main use-after-free.c:4
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
previously allocated by thread T0 here:
#0 0x44436e in __interceptor_malloc projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
#1 0x45913f in main use-after-free.c:3
#2 0x7fce9f25e76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:5 main
18

19. Metrics
• Figuring out the quality of an existing product
• Predicting the quality of a product
• Improving the quality of a product
19

20. Quantitative metrics
• Source lines of code (SLOC)
• The amount and percentage of comments
• Average SLOC per function/class/file
• Code duplication percentage
• Cyclomatic complexity
20

21. Defect metric
• Defect density in code
• Number of Defects – the total number of detected bugs
• Size – codebase size
21

22. • Open-source platform for continuous quality
control and analysis
• Contains a number of analysers for different
languages
• Integrates with third-party analysers
• Has means of visualising product quality
22

23. How does one use it
23

24. Prerequisites
• JRE 8
• SonarQube LTS
https://www.sonarqube.org/downloads/
• SonarQube C++ Community Plugin
https://github.com/SonarOpenCommunity/sonar-cxx
24

25. 25

26. Preparation
• Quality profile
• Quality gate
• Configuration file
26

27. Quality profile
27

28. Quality gate
28

29. sonar-project.properties
sonar.projectKey=demo
sonar.projectName=demo
sonar.projectVersion=1.0
sonar.projectBaseDir=SonarTest
sonar.sources=Thingy
sonar.host.url=http://localhost:9000
29

30. First run
30

31. Rules’ configuration
31

32. CppCheck
• Open-source static analyser
• Based on regular expressions
• Allows adding custom rules
• http://cppcheck.sourceforge.net/
32

33. CppCheck
33
sonar.cxx.cppcheck.reportPath=../cppcheck.xml

34. Clang-Tidy
• C and C++ linter
• Checks code style
• Allows adding custom rules
• Goes with LLVM
• https://clang.llvm.org/extra/clang-tidy/
34

35. Clang-Tidy
35
sonar.cxx.clangtidy.reportPath=../tidy.log

36. PVS-Studio
• Static analyser for C, C++, C#, and Java
• A plugin is needed to connect to SonarQube (shipped
with the product)
• https://www.viva64.com/
36

37. PVS-Studio
37
sonar.pvs-studio.reportPath=report.plog

38. Valgrind
• Open-source dynamic analyser
• Works under Linux
• http://www.valgrind.org/
38

39. Valgrind
39
sonar.cxx.valgrind.reportPath=../valgrind.xml

40. Code coverage
• Works well when used along with unit tests
• Gives estimation of how well different
execution paths are covered
40

41. Gcov
• Open-source utility for code coverage
• Part of GCC
• https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html
41

42. Gcov
42
sonar.cxx.coverage.reportPath=../gcov.xml

43. Result
43

44. Result
44

45. Result
45

46. Result
46

47. Result
47

48. Summary
• There are different tools for code
quality assurance
• Using them conjointly is a good
idea
• There’s no silver bullet
48

49. Q&A
• PVS-Studio:
https://www.viva64.com
• Contacts:
Yuri Minaev
minaev@viva64.com
49