Most influential programmers say that code must be self-documenting. They find comments useful only when working with something uncommon. Our team shares this opinion. Recently we came across a code snippet that perfectly proves it.
Perfect code *
How McConnell bequeathed
Users sometimes ask how new diagnostics appear in the PVS-Studio static analyzer. We answer that we draw inspiration from a variety of sources: books, coding standards, our own mistakes, our users' emails, and others. Recently we came up with an interesting idea of a new diagnostic. Today we decided to tell the story of how it happened.
There is an open project COVID-19 CovidSim Model, written in C++. There is also a PVS-Studio static code analyzer that detects errors very well. One day they met. Embrace the fragility of mathematical modeling algorithms and why you need to make every effort to enhance the code quality.
You may have already read a recent article about the first PVS-Studio run and filtration of warnings. We used the GTK 4 project as an example. It's about time we worked with the received report in more detail. Our regular readers may have already guessed that this article will be a description of errors found in the code.
Static analyzer PVS-Studio can detect bugs in pretty complex and intricate parts of code, and coming up with appropriate fixes for such bugs may be a tough task even for human developers. That's exactly the reason why we should avoid offering any options for automatic fixing at all. Here are a couple of examples.
By writing the article "Upsetting Opinions about Static Analyzers" we were supposed to get it off our chest and peacefully let it all go. However, the article unexpectedly triggered robust feedback. Unfortunately, the discussion went in the wrong direction, and now we will make a second attempt to explain our view of this situation.
Modern applications are built from third-party libraries like a wall from bricks. Their usage is the only option to complete the project in a reasonable time, spending a sensible budget, so it's a usual practice. However, taking all the bricks indiscriminately may not be such a good idea. If there are several options, it is useful to take time to analyze open libraries in order to choose the best one.
Hey guys! Let me walk you through the next part of our dark-style code academy. In this post, we will discover some other ways how to slow down the reading speed of your code. The next approaches will help you to decrease maintenance and increase a chance to get a bug in your code. Ready? Let's get started.
Do you want to raise your salary? Do you want always to be in demand? Do you want to have your job as long as you want? It is absolutely real! You just need to change the way you write your code. Basically, you need to increase your job security. You have to write code which will be almost impossible to maintain for everyone except you. And in these series of articles, I will tell you how to achieve it. Welcome under the cut.
The purpose of this article is not to help with integration but rather to elaborate on the technicalities of the process: the exact implementations of warning suppression mechanisms and pros and cons of each approach.
It is easy to try a static code analyzer. But it requires skills to introduce it in the development of an old large project. If the approach is incorrect, the analyzer can add work, slow down development, and demotivate the team. Let's briefly discuss how to properly integrate static analysis into the development process and start using it as part of CI/CD.
«Clean Code» and a clean cat
There is nothing developers enjoy better than arguing about clean code: Dan Abramov, for example, has recently fueled the hype with his blog post, «Goodbye, Clean Code».
However, “clean code” per se doesn’t even have a clear definition. The main book on the subject is Clean Code, where Robert «Uncle Bob» Martin states that there are perhaps as many definitions as there are programmers. But he doesn’t walk away from the fact with a conclusion that there’s no reason to discuss clean code, rather — compare several definitions and highlight general ideas. Therefore he cites the views of several outstanding programmers on what clean code is.
So we have also become interested in what people in 2020 think of clean code. Have the views changed since the publication of the book? Do opinions vary in different IT fields (maybe backend developers perceive the idea of clean code differently from testers)?
We've already published the results in Russian, and here's the English version. Since the topic is known to provoke discussions, feel free to give your own definition or argue about those already given!
UPD: When we posted this article, Uncle Bob had our conferences in his schedule. Unfortunately, the situation has changed. We updated this post on March 12, to avoid any misunderstanding.
Let's first have a look at the common things between the two:
1) Both support time-travel debugging
2) Both contain open-source libraries
3) Both provide a client-side state management
4) Both provide huge support for React native frameworks
In this blog, we have listed all the pros and cons of both state management solutions. It will help web developers to choose the best one for their next project. Before discussing this, we have compared both Redux and Mobx based on some parameters as given below:
When talking about "bad code" people almost certainly mean "complex code" among other popular problems. The thing about complexity is that it comes out of nowhere. One day you start your fairly simple project, the other day you find it in ruins. And no one knows how and when did it happen.
But, this ultimately happens for a reason! Code complexity enters your codebase in two possible ways: with big chunks and incremental additions. And people are bad at reviewing and finding both of them.
Our support chats and some other indirect signs showed that there are many students among our free users. Here's the reason: PVS-Studio is now more often used by professors in courses related to software development. We are very pleased with this, and we decided to write this small article to fall under notice of other teachers. We are pleased that students become acquainted with the methodology of static code analysis in general and the PVS-Studio tool in particular. Our team will try to contribute to this trend.
if constexprand generic lambdas so that code could use the type if it is defined, while still being accepted by the compiler (and being discarded) if the type is not defined.
However, our usage had a few issues, some minor annoyance, some more frustrating.
- You had to say
structall the time.
- If the type didn’t exist, the act of naming it caused the type to be injected into the current namespace, not the namespace you expected the type to be in.
- You must use the
structtechnique with an unqualified name. You can’t use it to probe a type that you didn’t import into the current namespace.
We can fix all three of the problems with a single solution: Predeclare the type in the desired namespace.
The goal of many bootcamp coding attendants is to move into a web development career. They do this by learning to build applications at a professional level – providing the foundation they need to build applications that are ready for production and demonstrating the skills they have to add real value to a potential employer.