The Unreal Engine project continues to develop - new code is added, and previously written code is changed. The inevitable consequence of the development in a project? The emergence of new bugs in the code that a programmer wants to identify as early as possible. One of the ways to reduce the number of errors is the use of the static analyzer, 'PVS-Studio'. If you care about code quality, this article is for you.
Although, we did it (https://www.unrealengine.com/blog/how-pvs-studio-team-improved-unreal-engines-code) two years ago, since that time we got more work to do regards code editing and improvement. It is always useful and interesting to look at the project code base after a two-year break. There are several reasons for this.
First, we were interested to look at false positives from the analyzer. This work helped us improve our tool as well, which would reduce the number of unnecessary messages. Fighting false positives is a constant task for any developer of code analyzers.
The codebase of Unreal Engine has significantly changed over the two years. Some fragments were added, some were removed, sometimes entire folders disappeared. That's why not all the parts of the code got sufficient attention, which means that there is some work for PVS-Studio.
The fact that the company uses static analysis tools shows the maturity of the project development cycle, and the care given to ensuring the reliability and safety of the code.
We won't be talking about all the errors that we found and fixed, We will highlight only those that deserve attention, to our mind.
Read more - https://www.unrealengine.com/en-US/blog/static-analysis-as-part-of-the-process
P.S. Those who are willing, may take a look at other errors in the pull request on Github. To access the source code, and a specified pull request, you must have access to the Unreal Engine repository on GitHub. To do this, you must have accounts on GitHub and EpicGames, which must be linked on the website unrealengine.com. After that, you need to accept the invitation to join the Epic Games community on GitHub.Instruction (https://www.unrealengine.com/ue4-on-github).
IT conferences and meetings on programming languages see a growing number of speakers talking about static code analysis. Although this field is quite specific, there is still a number of interesting discussions to be found here to help programmers understand the methods, ways of use, and specifics of static code analysis. In this article, we have collected a number of videos on static analysis whose easy style of presentation makes them useful and interesting to a wide audience of both skilled and novice programmers.
What is Static Analysis?
In this article we'll look at the main features of SonarQube - a platform for continuous analysis and measurement of code quality, and we'll also discuss advantages of the methods for code quality evaluation based on the SonarQube metrics.
SonarQube is an open source platform, designed for continuous analysis and measurement of code quality. SonarQube provides the following capabilities:
One of the main problems with C++ is having a huge number of constructions whose behavior is undefined, or is just unexpected for a programmer. We often come across them when using our static analyzer on various projects. But, as we all know, the best thing is to detect errors at the compilation stage. Let's see which techniques in modern C++ help writing not only simple and clear code, but make it safer and more reliable.
What is Modern C++?
The term Modern C++ became very popular after the release of C++11. What does it mean? First of all, Modern C++ is a set of patterns and idioms that are designed to eliminate the downsides of good old "C with classes", that so many C++ programmers are used to, especially if they started programming in C. C++11 looks way more concise and understandable, which is very important.
The development team working on PVS-Studio has finally started developing its product for Linux. That was the news that the CTO Andrey Karpov wrote about in the article. Long disputes and requests of the readers on habrahabr.ru, discussions on Reddit, Linux.org and other places can now gain a new round of comments. As it is mentioned in the article, you can volunteer to help the developers to test this product and improve it to a better level.
There are many tasks on the way of PVS-Studio to Linux, that the technical director is talking about. Put briefly, these are:
- more complete support of GCC and Clang;
- a new system of regression tests in Linux, so that you can track the changes results in the analyzer kernel and add new diagnostics;
- compiler monitoring to help programmers quickly and easily check the project without distracting people who support makefiles and the build system in general;
- documentation improvement, so that the user can get information with the examples about any diagnostic;
- testing, distribution, support organization.
In this article you will find more details about the abilities of PVS-Studio for Windows and the tasks it can already solve on Linux.
Often people ask questions - which programming language is easier, which is the most popular, which one to start learning and so on. In this article we will compare two languages Python and Ruby; their reference implementations CPython and MRI, to be exact.
We took the latest versions of the source code from the repositories (Ruby, Python) for the analysis. There weren’t many glaring errors in these projects. Most of them are related to the usage of macros, although this code is quite innocent from the point of view of the developer. But at the same time, such suspicious fragments that occurred because of copy paste, comparing SOCKET type with null, undefined behavior, storing values to the variables that are already used or null pointer dereferencing are really worth reviewing.
Having analyzed all the warnings of general analysis diagnostics and removed all the false positives, we have come to the following conclusion concerning the error density:
More details about the code fragments where these suspicious code fragments were found:
It’s worth saying that despite these flaws, the code is still of high quality. We should also take such factors into account as the size of the codebase , or the fact that some fragments are erroneous only from the point of view of C++ language and they don’t affect the program in any way. That’s why this analysis may be rather subjective, because previously we haven’t evaluated the error density of these projects. We’ll try to do that in the future, so that we can later compare the result of the checks.
The PVS-Studio team have written an interesting article about the ways in which you might shoot yourself in the foot working with serialization, code examples, where the main pitfalls are, and also about the way static code analyzer can help you avoid getting into trouble.
This article will be especially useful to those who are only starting to familiarize themselves with the serialization mechanism. More experienced programmers may also learn something interesting, or just be reassured that even professionals make mistakes.
However, it is assumed that the reader is already somewhat familiar with the serialization mechanism.
Nowadays a lot of projects are opening their source code and letting those who are interested in the development of it edit the code. OpenJDK is no exception, programmers PVS-Studio have found a lot of interesting errors that are worth paying attention to.
OpenJDK (Open Java Development Kit) - a project for the creation and implementation of Java (Java SE) platform, which is now free and open source. The project was started in 2006, by the Sun company. The project uses multiple languages- C, C++, and Java. We are interested in the source code written in C and C++. Let's take the 9th version of OpenJDK. The code of this implementation of Java platform is available at the Mercurial repository.
During verification, the analyzer found different errors in the project including: copy-paste, bugs in the operation precedence, errors in logical expressions and in pointer handling and other bugs, which are described in detail in this article.
It's always amusing to check a project which is used and maintained by a large number of people. The better and more accurate the code is, the more safely and effectively the program will work. Those bugs we found, are another proof of the usefulness of an analyzer, as it allows the detection of such errors which would otherwise be hard to detect doing simple code review.
Roslyn is a platform which provides the developer with powerful tools to parse and analyze code. It's not enough just to have these tools, you should also understand what they are needed for.
The article can be divided into 2 logical parts:
General information about Roslyn. An overview of tools provided by Roslyn for parsing and analyzing the code. We provide a description of entities and interfaces, as well as the point of view of a static analyzer developer.
Peculiarities that should be taken into account during the development of static analyzers. Description of how to use Roslyn to develop products of this class; what should be considered when developing diagnostic rules; how to write them; an example of a diagnostic.
This article is intended to answer these questions. Besides this, you will find details about the static analyzer development which uses Roslyn API.
More: Introduction to Roslyn and its use in program development
Here is a small e-Book for your attention: The Ultimate Question of Programming, Refactoring, and Everything. This book is intended for C/C++ programmers, but it could be of interest for developers using other languages as well.
What makes the book peculiar is the descriptions of real, not theoretical cases at the base of it. Each chapter starts with a code fragment taken from a real application, and then the author gives various tips of how this bug could be avoided. The questions touched upon in this book can help the readers improve the personal coding style and the coding standards used in the team.