Changes in the infrastructure of tools for programmers

    The set of tools used by the developer is regularly updated. Completely new tools appear, some cease to be relevant, some cease to develop and are superseded by more advanced analogues. It’s quite interesting to observe all this, and I decided to share some of my latest observations in this area.

    I also want to note right away that the position is close to me, that the less heterogeneous tools used, the better. I am prepared in advance for criticism in the minimalism of functionality. My position is controversial, but it deserves the right to exist.

    Automated Testing

    Some functionality that was previously only available using third-party utilities is gradually moving into development environments. In particular, in Visual Studio. However, this functionality is still associated with developers only with third-party tools. An example is the automated application user interface testing system introduced in Visual Studio 2010 Premium / Ultimate, which makes it possible in many cases to abandon tools such as AutomatedQA TestComplete or Borland SilkTest.

    Please understand me correctly. I do not at all propose to abandon the existing test base and urgently begin the transition to the testing system built into Visual Studio 2010. And I am not at all campaigning for its use. TestComplete is one of the most powerful commercial products designed to automate software testing. However, if you are using Visual Studio 2010 and deciding on the choice of an automated testing system for a new project, then perhaps you should not go far. If you do not need special specific features during testing, then you will not have to buy and use additional systems besides Visual Studio 2010.

    We use the user interface testing system from Visual Studio to test the PVS-Studio interface. Earlierwe were more focused on testing internal modules, but with the growth of the interface part, the task arose to switch from manual testing to automatic testing. Nevertheless, our requests are rather modest and we are pleased that we chose testing in Visual Studio. Figures 1 and 2 show some windows of the Visual Studio testing system during operation.

    Figure 1 - Recording user actions in Visual Studio

    Figure 2 - The tree of controls in Visual Studio

    Conclusion - it is beneficial to study the innovations in the tools already in use. If you have standard testing requests, then perhaps you have enough Visual Studio functionality when developing new projects. Thus, the number of entities (tools) with which you deal will not increase, and this is always good.

    Code editor

    Similarly with testing, the situation is with the assistant - Visual Assist. I remember how good it was with him in the days of Visual Studio 6.0. But many talk about its usefulness, simply not knowing about the modern capabilities of the latest Visual Studio or not noticing them. Most of the features that I appreciated so much in Visual Assist were gradually implemented in Visual Studio. Starting with Visual Studio 2008, I came to the conclusion that I can safely do without Visual Assist and refused to use it. With the release of Visual Studio 2010, using Visual Assist has become completely irrelevant for me.

    I don’t argue, there are functions in Visual Assist that Visual Studio will never enter. And I’m sure that for some these functions are important or just convenient and useful. There are many people for whom Visual Assist over time does not lose any importance, but on the contrary becomes more and more indispensable. However, I personally used a very modest assortment of opportunities and did not feel the need for more. And these features are now satisfied with Visual Studio. I will consider a few examples, armed with Visual Studio 2010.

    There is a syntax coloring. Let it not be as colorful as in Visual Assist, but quite nice and sufficient for me. And if you take into account the underlining of syntax errors, it’s generally wonderful (see Figure 3).

    Figure 3 - Code highlighting in Visual Studio 2010 and underlining of incorrect constructions.

    A system of hints for function parameters and name hints for the first entered character names work well (see Figures 4 and 5):
    Figure 4 - Hint for function parameters in Visual Studio 2010

    Figure 5 - Hint for function names in Visual Studio 2010

    There is a feature that I really missed without Visual Assist. This is a file name hint. In Visual Studio 2010, this feature appeared (see Figure 6).

    Figure 6 - Hint for the names of the connected files in Visual Studio 2010

    Visual Assist helped me figure out even poorly formatted code when I needed to understand where the parenthesis opens and closes. Visual Studio 2010 provides the same functionality by highlighting pair brackets, as shown in Figure 7.
    Figure 7 - Highlighting pair brackets in Visual Studio 2010 The

    functionality of the code editor in Visual Studio 2010 completely satisfies me. Perhaps you will take a look at this Visual Studio editor again.

    Static analysis

    When it comes to static analysis of C ++ code, the programmer often has an association: “These are some tools like lint that have a command-line interface and which are no longer relevant.” Let's try to figure out how this opinion arose. I will not talk about companies and mature development processes where static analysis has been used before, is used now and will be used in the future. But most use immature processes. Do not be shy about this. This is not a disadvantage of programmers, but of organizations. For them, a static analyzer is still more exotic than an everyday tool integrated into the development process.

    The C language is a language that requires great accuracy and attention from the programmer, since it controls the actions performed in the code very weakly. The more dangerous language is, perhaps, only assembler. In this regard, tools for static code analysis appeared, the most famous representative of which is lint. This and similar tools were used quite widely due to the lack of alternative ways to detect errors at the coding stage. They were relevant for software development cycles of any maturity level.

    The new C ++ language, due to more stringent type control and other enhancements, has become much more secure. Compilers for C and C ++ began to issue warnings about many potentially dangerous situations. In fact, they took over many of the functions of existing static analyzers, and the use of the latter became less popular. At this point, many refused an additional level of analysis using third-party tools.

    However, static analyzers are not at all obsolete. They learned to detect many types of errors related to object-oriented programming, to warn about the incorrect use of libraries (for example, Qt), and even to detect errors in parallel programs. Consequence - static analyzers, as before, can significantly reduce costs at the testing and support stage. And what’s nice, now these are usually not separate tools, but modules that integrate into the development environment.

    I would like to emphasize that the opinion of static analyzers as obsolete command-line solutions is itself outdated. These are modern tools that perfectly complement the standard compiler features and other tools to improve the quality of programs.

    As an example, take Visual Studio again. Starting with Visual Studio 2005, the Team System version includes the Code Analysis general-purpose static analysis subsystem . Although the system is an extension, it is tightly integrated into the environment and working with its diagnostic messages is similar to working with messages issued by the compiler (see Figure 8).
    Figure 8 - Code Analysis settings tab in Visual Studio 2010

    There are other specialized specialized static analyzers. As an example, I can cite the PVS-Studio analyzer we are developing , which also integrates tightly into Visual Studio (see Figure 9) and allows you to identify many errors in 64-bit and OpenMP programs.
    Figure 9 - PVS-Studio integration in Visual Studio 2010

    Modern static analyzers are user-friendly programs that not only professionals, but also programmers, who have just started working, can work with them.

    Dynamic analysis

    Speaking about a dynamic analyzer for finding memory errors, first of all, everyone remembers the DevPartner BoundsChecker Suite tool. However, I want to reduce the ardor of his supporters and those who recommend it in the forums. Undoubtedly, it has been a wonderful and indispensable tool for a long time. Unfortunately, the project is not currently developing and is rapidly becoming obsolete. For example, BoundsChecker does not support Win64 applications. It is able to run in a 64-bit environment and check 32-bit applications, but it cannot work with 64-bit applications. Quote from the booklet: “DevPartner Studio supports 32-bit application development on 64-bit Windows ( WOW 64 ).”

    This kind of lag is unacceptable for testing tools. Fortunately, BoundsChecker and other dynamic analysis tools have been replaced by a new titanium, which is much more reasonable to focus on. This is an Intel Parallel Inspector tool included with Intel Parallel Studio.

    Intel Parallel Studio integrates into Visual Studio (see Figure 10) and adds the ability to check the work with memory and threads. Checking memory in the Intel Parallel Inspector includes checking for memory leaks, detecting pointers that reference a remote object, and detecting work with uninitialized variables. Intel Parallel Inspector allowsidentify the use of incorrect references to memory areas, controls the stack and so on. Flow checks include race condition checks, deadlocks, call stack analysis with adjustable depth.
    Figure 10 - Setting the diagnostic level in Intel Parallel Inspector

    The best part is that you can analyze programs built using Intel C ++, or using Visual C ++. The analysis of Win32 and Win64 applications is supported. Intel Parallel Studio is developing steadily, has a low price and its use can be safely included in long-term plans.


    The infrastructure of tools for programmers is constantly changing. You can find both new, more convenient solutions, and abandon some of the old ones (due to the cessation of their development). By the way, large companies have special employees (and even departments) who are engaged only in monitoring the development of tools used in the development process.

    Also popular now: