Tuesday 19th May, 2020
If there is any single consolation amidst the circumstances we are all having to cope with at the moment it is that many of us have lots of time to fill - not only with unproductive things like binging Netflix (I really should get around to watching Dirk Gently's Holistic Detective Agency...) but also with tasks which might have a more lasting long-term benefit.
Those could be tasks like learning a language (programming or human), joining online yoga classes, writing a book, designing a website, blogging, reading (I can recommend Francis Buontempo's Genetic Algorithms and Machine Learning for Programmers if you fancy learning a little about ML) or generally just getting on with stuff with perhaps fewer distractions than usual.
On the latter note, for the past few months we've been working on the codebase of the next version of Visual Lint in our development branch, and it is coming along quite nicely.
One of the things we have planned to do for some time is to add direct support for the Clang-Tidy analysis tool to Visual Lint. When the UK lockdown started, focusing on this task in particular proved to be a very useful distraction from all the fear and uncertainty we found around us.
Sometimes being in the zone helps in more ways than usual.
The screenshot above should give you an idea of where we are at the moment. Whilst there is still a great deal to do before we can consider this is production-ready the foundation is in place and it is definitely usable. For example, selected issues can already be suppressed from the Analysis Results Display by inserting inline suppression directives ("// NOLINT") using the same context menu command used to suppress (for example) PC-lint, PC-lint Plus and CppCheck analysis issues.
With Microsoft Visual Studio being one of the major development environments we support one of the most important things to address is configuring Clang-Tidy to be tolerant of non-standard Visual C++ projects. The errors shown for some files in the Analysis Status Display in the screenshot above are exactly because of this - a standards compliant C++ compiler is likely to generate at least some errors while compiling most Visual C++ projects.
The only error we saw in the Visual C++ project mentioned above was: clang-diagnostic-error: -- call to non-static member function without an object argument.
The StackOverflow topic Refactor MFC message maps to include fully qualified member function pointers discusses exactly the same issue.
This is mitigated by the fact that recent versions of Clang-Tidy do a pretty good job of handling nonstandard code, so the things that Clang-Tidy warns about seem to be exactly the sort of things you would expect it to and a fair degree of tuning is possible. For example, the clang-diagnostic-error issues in the case above could be disabled entirely if that was what you wanted (as it's a trivial fix you could alternatively choose to correct the code).
Furthermore, with the C++ Core Guidelines checks enabled (e.g. using the --checks=modernize-* switch) Clang-Tidy can tell you exactly what you could do to your C++ code to bring it up to modern standards.
We will obviously be talking more about Clang-Tidy in due course - particularly once we start looking at using it to automatically correct the issues it finds (if you are not aware, this is one of the most compelling features of Clang-Tidy. The good news is that autofixing selected issues should be fairly straightforward using the output of the Clang-Tidy --export-fixes switch.
Lockdowns or eased lockdowns, more interesting times lie ahead.
