Products, the Universe and Everything

The Riverblade Developer's Blog

Beth demonstrating Visual Lint at the ACCU Conference 2008  Anna taking part in a discussion panel at the European Software Conference 2007 

Welcome to our developer's blog. We hope that this forum provides an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

Current Entries | Archives |


Code Editor Markers in Visual Lint
Tuesday, April 27, 2010

For some time now we have wanted to enhance Visual Lint to make use of the code editor customisation capabilities of Visual Studio. With Visual Lint 2.5 out there, our development branch is now focused on the next version of Visual Lint (due out next Spring), and that is giving us the opportuity to start looking at more ambitious new features.

One obvious thing to do is to add code editor markers for analysis issues. In their simplest form, these take the form of icons displayed in the margin of the code editor - the most familiar uses being for breakpoints and bookmarks.

Fortunately, recent versions of Visual Studio provide interfaces to allow you to do this - albeit ones which are complex and rather poorly documented.*

* These are VSIP interfaces (the lowest and most complex level of Visual Studio Extensibility, and the one used to integrate language services such as Visual C++ and Visual C# into the IDE) rather than automation interfaces as normally used by Visual Studio add-ins.

The basic idea is simple - place a marker in the code editor wherever an analysis issue is detected. In practice, it is somewhat more complex than that, as you then need to decide how the user will interact with the new marker and detect and handle line deltas (due to editing etc.) as they arise.

However, as a starting point, we have now implemented basic markers (using the same icons as the Analysis Status and Results Displays) in the Visual Lint development branch:

Basic markers implemented in the Visual Studio 2008 code editor.

Hovering over a marker will of course yield a tooltip which describes its meaning:

Hovering over a marker will yield a tooltip which describes its meaning.

There are some interesting subtleties involved with doing this. For example, many lint issues report their line number as the line at which the effort of the issue makes itself felt, rather than where the code fragment that causes it is. In such cases, a corresponding "Reference/Location cited in prior message" issue will locate the offending bit of code.

In marker terms, this means that the marker which actually locates the problem may be a generic location marker, and therefore not as helpful as it could be. Our approach to this is to attempt to highlight the code fragment which actually caused to the issue, as you can see in the following screenshot:

Highlighting the offending symbol in the code itself.

Ultimately, we want to make these interactive by adding a context menu which will allow the user to suppress (or even fix!) a specific issue directly from the code editor. That said, we feel that this is a good starting point for the development of a set of potentially very complex functionality.


Posted by Anna at 14:28 | Get Link

 

Visual Lint for Eclipse/CDT
Friday, April 23, 2010

For some time we have looking at producing versions of Visual Lint for non-Microsoft development environments, and as part of that effort we have been looking at the feasibility of developing a Visual Lint plug-in for the Eclipse/CDT environment (which is of course widely used within the embedded market).

That effort is now starting to make real progress, and as a result an early preview of the resulting Visual Lint for Eclipse product was demonstrated on our stand at the ACCU Conference last week. Needless to say, it garnered quite a bit of interest - so much so that we're considering doing a version capable of analysing Java code at some time in the future.

In the meantime, we're focusing on Visual Lint for Eclipse/CDT. This is a direct port of the existing Visual Studio product, and therefore all of the capabilities and displays of Visual Lint will be available within the Eclipse/CDT environment:

Visual Lint for Eclipse/CDT

We expect to be able to make development builds of Visual Lint for Eclipse available to Visual Lint beta testers during the summer.


Posted by Anna at 13:27 | Get Link

 

ACCU Conference 2010
Wednesday, April 14, 2010

Note: this topic is a work in progress, and will be expanded as I get time to write up my notes from the conference.

Once again we're in Oxford for the ACCU Conference - a week of almost solid learning, discourse, networking and of course socialising. This is the fourth year we have attended the Conference, and from experience we know that by the time it finishes on Saturday afternoon we will be absolutely exhausted! Nevertheless, the amount we learn here every year (and the excellent in-bar conversations at the end of each day) makes this conference more than worth it.

As we arrived on Tuesday afternoon we had a bit of time to relax before things really got going (which they did in the evening, with seventeen of us descending on a restaurant in town and then monopolising the hotel bar afterwards...).

Our stand at ACCU 2010, complete with giveaways from our local sweet shop in Bournemouth! The two leftmost displays were connected to our grid analysis demonstrator, whilst the laptop on the right ran a rolling demo.

 

Day 1 - Wednesday

This morning after dropping off our gear in the exhibitors area we joined a friend for breakfast and then headed down to set up our stand (an activity which almost always holds a few unexpected last minute surprises).

 

The Evolution of Scrum (Jeff Sutherland - Keynote)

This was the first session of the conference proper, and as such the main conference room was packed to the gills. As we were delayed by setting up the stand we ended up right at the back of the room, so I couldn't see the slides particularly well, but fortunately that wasn't a problem for this session.

Jeff gave an interesting overview of the history of Scrum and its core principles, before doing the same with Lean Software Development and then going on to give examples of how Scrum and Lean have fared in environments where their success has been directly measured by comparison with traditional approaches (a notable example being a CMMI Level 5 company which was sufficiently impressed by the achievements of Scrum teams that they started bidding Scrum projects at 50% of the cost of the waterfall equivalent).

I've not worked on a Scrum team myself so I don't have an informed view of its advantages and disadvantages relative to other agile processes. It is however beyond doubt that it can be very effective, but that to be so the organisation must embrace not only the mechanisms of Scrum but also its core principles. That of course requires that the organisation must not only change itself, but also must welcome that change. Unfortunately experience tells us that far too many organisations struggle to do that.

 

Using Concurrency in the Real World (Anthony Williams)

Using Concurrency in the Real World

Anthony is the author of the Boost threading library, and an authority on the new threading capabilities of C++ 0x.

In this session he talked about the (by now well understood) difficulties with designing multithreaded software before going on to describe core principles (e.g. carefully considering which data must be shared and avoiding hidden dependencies, singletons and globals) to apply in order to write simpler, more effective concurrent applications.

Among the simple but interesting techniques Anthony described were the use of a SynchronizedValue template class to wrap a value type with its own lock (reassuringly, this is a technique we already use extensively in our own code, albeit under a different name) and a templated DataFlowVariable type which executes operations in terms of tasks and can be used to produce scalable codebases very easily. The latter in particular is something I think we could learn from when we next review the way we use tasks in our codebases.

He then went on to describe how new C++ 0x threading features such as futures (which provide a simple way of executing a task and waiting for a result to become available) and std::async (which automatically scales the number of threads spawned to the capabilities of the hardware) can also assist.

 

Googletest and Googlemock C++ libraries (Seb Rose)

This session was (like the previous one) packed out. A notable late arrival who didn't get a seat was Kevlin Henney - which is almost karma, given how packed his sessions at the Conference usually are!

Googletest is an xUnit unit test framework developed to support the development of the Chrome browser. Like most C++ unit test frameworks, Googlemock is macro based and has only a console runner, which can be configured via command line options. One nice touch is that the pass/fail output is colour-coded.

Seb demonstrated running test fixtures within Visual Studio,with test results directed to the output window. In this environment double clicking on a failure message in the Output Window opens the source at the failing test as you would expect.

One quirk is that exceptions must be explicitly tested for, whereas most xUnit test frameworks will automatically fail the tests if an unexpected exception occurs. Under Windows, the option -gtest_catch_exceptions overcomes this limitation.

The mocking framework Googlemock is a templated framework based on jMock and using tr1::tuple. Interestingly it does not require Googletest, but should work with any test framework. Because of its template nature, it does however impose a significant compilation time penalty.

Quite reasonably, it can only mock virtual methods. It does however look quite flexible - allowing (for example) a test to define sequences of expected calls and parameters into a mock, and in what order.

 

The C++ 0x Standard Library (Nicolai Josuttus)

The C++ 0x Standard Library

This was a detailed in study of the new features in the C++ 0x Standard Library, including all of the things you would expect - initialiser lists, new containers, auto variables, tuples, r-value references, move constructors etc.

The new version of the C++ standard introduces so many changes that even a detailed study can only just scratch the surface, and there is certainly too much for me to even begin to do justice to it in a mere blog post. If you are planning to move your codebase to C++ 0x in even the medium term I can only suggest that it would be a good idea to start familiarising yourself with the changes (and their implications and the resultant opportunities) as soon as you can.

 

Sponsors Reception

Following the session there was an hour long break before the Sponsor's Reception at 6:30pm, which is as ever our chance to showcase our products, answer enquiries and and make some new contacts over a glass or two of wine. This year we have quite a bit of new stuff to showcase so we have a lot to talk about.

Thence to the bar, of course....

 

Day 2 - Thursday

After the reception yesterday afternoon we packed down the equipment from our stand and congregated with other delegates in the bar for discourse (and of course, beer). In due course, a trip to Chutney's Indian Restaurant in town was proposed, taxis were booked and we continued our discourse over a curry and (of course) more beer.

After we returned those unfortunate enough to wander into the hotel bar and stay into the early hours of the morning were of course fated to join the ranks of "The Lakosed" and hence were distinctly wobbly this morning.

 

Hello! I'll Be Your Tester Today (James Bach - Keynote)

I have a feeling that this when we come to the end of this year's ACCU Conference a significant proportion of delegates will have this pinned down as their most memorable session. Certainly, this was the funniest one I've been for a while.

James' started out with a simple question, and an equally simple (but brutally honest) answer:

Question: What do testers do that's special and different from developers?

Answer: We break stuff (or more accurately: you broke it when you wrote it, and we just found you out!)

He then went on the give a very humorous description of the role and mindset of a consultant tester, using (among other things the dropped calculator example). His delivery was infectiously funny and as a result we spent most of the time laughing. His captioned re-interpretation of The Towering Inferno (reproduced below) gives a small insight into how he sees the tester's craft:

One interesting observation was that with the advent of agile software development, development teams effectively got so fed up with the process people  (who are the same people that testers have been fighting for years) that they fired their testers.

Automated functional testing is one of James' big beefs with the software industry. He eloquently demonstrated that human based testing offers something that an automated test just cannot - for example intuition, and thinking "outside the box". Automated systems just can't do that - which is why they excel at unit level testing, and fail miserably at end-user testing. Most importantly, they cannot offer communication and feedback to developers in the same way as human testers.

He then went on a very funny excursion through some of the techniques testers may use, notably the "Click Frenzy", the "Shoe Test" (any test consistent with pounding on a keyboard with a shoe!), and "Branching and Backtracking".

One important point made was that testing is a heuristic activity encompassing a teachable set of skills. It's not just "playing around". Untrained testers immediately start writing test cases, based on assumptions they aren't aware of and don't even know how to think through.

Quote of the session "I'm testing outside the specification because the specification is a rumour."

 

Genemodulabstraxibilicity (Steve Love)

"The feeling that it's just too difficult"

This session was a discussion of code and design smells, and the problems they can lead to - all ably illustrated by quotes from Edserger Dijkstra, Terry GIlliam et all.

Before starting that discussion, however, Steve observed that when we code, we strive for an often conflicting set of goals (maintainability, etc etc) and that in doing so we often sacrifice simplicity. If however we instead strive for simplicity the rest will generally follow.

The classical corporate response to such smells is of course to lay down a rigid set of rules which proscribe certain constructs or structures. Unfortunately, this all too often becomes a dogma in its own right, with the original meaning being lost.

For example, one C++ coding standard I encountered early in my own career contained the edict "Do not use multiple inheritance" (on the grounds that it was a powerful technique which was likely to be cause maintenance headaches for inexperienced developers) which today seems quite ludicrous. I wonder if that rule has been removed yet, or whether the company in question is still insisting that developers blindly follow it, despite having long forgotten why the rule was written in the first place...?

Worse, the sheer number of design and code smells (of which Steve could only mention a limited number, even in a 90 minute session) makes such a proscriptive approach even more unrealistic.

So, rather than issue such proclamations, would it not be better to encourage developers to actually think for themselves and make their own informed judgements instead? We are, after all, supposed to be software professionals.

 

Stood at the bottom of a Mountain looking up (Pete Goodliffe)

Pete Goodliffe: Stood at the Bottom of a Mountain, Looking Up.

This session dealt with learning and learning curves. The "mountain" in the session title refers to the mass of "stuff" we know we don't know when we join a new project.

As software development is a knowledge profession, it requires that we constantly learn. However, learning (or more accurately being aware of how little we actually know about an as yet unfamiliar subject) can be frightening. Learning is difficult, and becomes harder as systems and technologies become more and more complex. It's a tough problem, but one we have to face if we are to succeed in our profession. At the end of the day it is our own responsibility to keep learning and evolve our understanding and knowledge.

Moral of this session: Always question what you're learning, and why. Beware of the obvious, and continually question your preconceptions and prejudices.

 

TDD at the System Scale (Steve Freeman & Nat Price)

Steve Freeman and Nat Price are the authors of Object Oriented Software Guided By Tests, and this session promised to be an interesting one.

In most projects, developers who practice test driven development do so on small functional blocks (classes, functions etc.) and then try to glue them together to form a meaningful system. By contrast, this session described the presenters' experience in applying TDD principles to a financial system at system level (i.e. a "system-test first" test driven development). That's a very ambitious goal.

One way to do this is to interface directly to a domain model (which by definition does not include the external interfaces) within the application. As such, it requires that the application be structured in such a way as to make such testing practical - i.e. that the high level design of the application - rather than just individual components of it - be amenable to automated test. Hence a system level TDD approach may also require system level decisions to be made at an earlier stage than would be normal in a traditional TDD project. As such, this can be a scary concept to some organisations since it forces them to make and commit to such decisions early.

TDD at the System Scale

In addition to the obvious design constraints, there are some real practical difficulties (asynchronous behaviour being an obvious one) to overcome in doing this sort of testing. Nevertheless, they seem to have managed it.

I must admit I did like their concept of using audit events as an alternative to logging.


Posted by Anna at 18:22 | Get Link

 

Introducing Visual TICS
Thursday, April 08, 2010

I tweeted about this a little while ago, but with the ACCU Conference nearly upon us it is about time we blogged about it.

The Visual Lint codebase has been in existence for over 5 years now. Although on the surface the current product appears to be a straightforward evolution of its original incarnation, in practice the structure of the codebase has changed significantly since the first public build in November 2005. From humble beginnings as a single small Visual C++ project it has now grown to no fewer than 40 projects containing between them over 300,000 lines of code (much of that is non-deliverable components such as unit test projects and supporting tools, course). One of the results of that growth (and the refactoring we apply to our codebase on an ongoing basis) is that the Visual Lint core itself is now much more reusable and customisable than when it started out.

One consequence of this is that we are now able to look at new Visual Lint integrations (for example Eclipse/CDT and a standalone Visual Lint application, both of which are now in development). Another is that we can leverage parts of the code for other products (something which has already borne fruit in LintProject Pro, and will shortly do so in ResOrg).

Which brings me up to February this year, when we were approached by Tiobe (the vendor behind the ClockSharp C# static analysis tool) with a view to us producing a Visual Studio add-in for their TICS framework.

TICS is a rule based layer which abstracts software quality tools from multiple vendors and provides configuration and analysis results in a standard format. In effect, it is another integration tool - albeit one which provides a command line interface rather than a graphical user interface. Supported analysis tools include such diverse products as Tiobe ClockSharp and Microsoft FxCop for C# and Parasoft C++ Test, GrammaTech CodeSonar and Programming Research QA C++ for C/C++.

Tiobe saw us as a vendor with proven experience of Visual Studio Extensibility and wanted us to produce a more full-featured add-in than their own in-house add-in product. Although we initially planned to write something custom from scratch, when we studied the requirements it become obvious that the best way to meet them was to produce a custom version of Visual Lint which interfaces to TICS rather than PC-lint.

As we had previously done some exploratory work on integrating other analysis tools (notably FxCop), most of the hooks we needed to do this were already in place, so much of it was a case of turning off functionality which was not required and rebranding. There were a handful of surprises, but nothing too major.

The result is a product called "Visual TICS", of which two development builds have so far been delivered to Tiobe for evaluation and feedback:

Visual TICS currently supports C/C++ and C# projects and uses the Visual Lint core engine and displays to schedule analysis tasks and present analysis results in exactly the same way as Visual Lint. If you have already used Visual Lint, you would find the user interface to be both familiar and consistent.

Rather than the conventional perpetual licences we use for Visual Lint, Tiobe plan to offer Visual TICS as an optional component of TICS site licence subscription packages. As such, it will not be appearing in our online store, so any sales enquiries must be directed to Tiobe. We are however of course happy to answer any licencing or technical questions any of our customers may have about it.


Posted by Anna at 17:10 | Get Link

 

LintProject Pro 2.0.7.15 has been released
Monday, April 5, 2010

The following changes are included in this build:
  • Corrected a bug in the parsing of .vcproj project files introduced in the previous build [VS2002-VS2008].

  • Updated the theme of the installer to match that used in the Visual Lint installer.

  • Minor updates to the readme file packaged within the installer.

Posted by Anna at 13:17 | Get Link

 

LintProject Pro 2.0.6.14 has been released
Thursday, April 01, 2010

The following changes are included in this build:
  • Trailing backslashes on intermediate folder paths are now filtered out before generating the PC-lint command line. This is necessary as PC-lint will raise an erroneous warning 686 and abort analysis when presented with a directive of the form -i"FolderName\".

  • $(NoInherit) and $(Inherit) macros found within Visual Studio project files and property sheets should now be correctly processed [VS2002-VS2008] [from Visual Lint 2.5.1.128].

  • $(NoInherit) or $(Inherit) macros found in project settings are now stripped from generated project.lnt files [from Visual Lint 2.5.1.128].

  • For Loop compliance is now correctly defined when specified in a Visual Studio property sheet (.vsprops) file [VS2002-VS2008] [from Visual Lint 2.5.1.128].

  • MsBuild property sheet user macros are now correctly processed [VS2010] [from Visual Lint 2.5.1.128].

  • Added support for MSBuild properties (e.g. MSBuildToolsPath) introduced in the VS2010 RC [VS2010] [from Visual Lint 2.5.1.128].

  • Property sheets specified as relative filenames in a .vcxproj project file are now parsed correctly [VS2010] [from Visual Lint 2.5.1.128].

  • Corrected a bug in the parsing of MSBuild project files which do not explicitly specify the name of a project [VS2010] [from Visual Lint 2.5.1.128].

  • VS2010 project file properties (e.g. UseOfATL and UseofMFC) which have been renamed by Microsoft between VS2010 B2 and RC are now correctly loaded [VS2010 RC] [from Visual Lint 2.5.1.128].

  • Added support for the IntDir, OutDir and ConfigurationType properties in .vcxproj project files [VS2010] [from Visual Lint 2.5.1.128].

  • Corrected a bug in the handling of user macros within Visual Studio property sheet (.vsprops) files [VS2002-VS2008] [from Visual Lint 2.5.0.127].

  • Added limited support for the $(TargetDir) variable within project configurations by aliasing it to $(OutDir) [VS2002-VS2008] [from Visual Lint 2.5.0.127].

  • Corrected a bug in the project file reader which caused Visual Studio inherited property sheet (.vsprops) files referenced via relative paths of the form "\foldername\filename.ext" to be located incorrectly [from Visual Lint 2.5.0.125].

  • Updated the PC-lint 9 message database to include changes (messages 83 and 457) and new messages (1084-1085, 1096-1111 and 1574) included in the updated msg.txt file for PC-lint 9.00d [from Visual Lint 2.0.10.124].

Posted by Anna at 11:22 | Get Link