Perfect code *

If you use static analyzers, you will have, sooner or later, to address the task of making their integration into existing projects easier, where fixing all warnings on legacy code is unfeasible.

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.

I don't know about you, but I really like to get inside all sorts of systems. In this article, I’m going to tell you about the internals of Lua tables and special considerations for their use. Lua is my primary professional programming language, and if one wants to write good code, one needs at least to peek behind the curtain. If you are curious, follow me.

^{«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)?

This spring, Uncle Bob comes to St. Petersburg to give talks at our three conferences: they are about .NET development, testing and JavaScript. Therefore, we’ve asked speakers from each of those conferences to share their opinion on clean code so we could compare the opinions of the industry experts in 2020.

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.

Visual Studio 2019 versions 16.3 and 16.4 include improvements to the C++ inliner. Among these is the ability to inline some routines after they have been optimized, referred to as the «Zipliner.» Depending on your application, you may see some minor code quality improvements and/or major build-time (compiler throughput) improvements. 

In JavaScript, state management is a hot of discussion these days. When it comes to implementing state management, developers often find it challenging dealing with boilerplate code in Redux. Hence, MobX has proved to be a good alternative to Redux which gives the same functionality with less code to write. However, both state management tools work well with React.

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.

Last time, we used SFINAE to detect whether a type had a definition, and we used that in combination with if constexpr and 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 struct all 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 struct technique 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.

Here is tree with 3 levels to start your journey as web developer.

A coding bootcamp is a program of technical training teaching the programming skills that employers are looking for. Coding bootcamps allow students with low skills to concentrate on the most significant coding aspects and apply their new coding skills to solve real-world problems.

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.

I often rail at technologies I find inadequate, and in response I receive (along with arguments) sheer anger and pain. Sometimes physical.

Developers take critique of their favorite technologies very personally for some reason. This “cult of the tool” is such a strange phenomenon I can’t explain it logically. Some say everyone’s prone to it, because a coder’s thinking processes intertwine very deeply with his programming language. Some say it’s a junior’s fallacy — you write something for the first time, it works, and you start treating your language like something divine.

Whatever it is, I never understood it.

I always considered cultists as imbeciles. But I always try to understand why imbeciles became them, why I’ve avoided that fate. I start thinking and bam! — it turned out I’m also an imbecile. I’m a cultist who worships F#. And, of course, there’s a story behind it.

Just about the fastest portable 64-bit hash function with decent quality.

This is a translation of the original article by Leonid Yuriev.