0 post

Posts Tagged ‘Visual Studio’


Real developers don’t need tools

Posted by Alen Zukich   July 15th, 2010

As the topic suggests, this kind of argument has been around for some time.  Most developers can recognize the need for tools but once you start breaking the developer’s day-to -day workflow you might as well flush that tool down the drain.

What developers need is a tool that seamlessly integrates with their development environment and their workflow, so they can meet their quality goals without taking a big productivity hit.

It’s one thing to provide plug-in tools for the more popular IDEs like Visual Studio and Eclipse, but it’s an added bonus when defect detection is a seamless part of the edit cycle. No buttons to click, just continuous analysis and issue highlighting while you work.

Let’s take the analogy to the spell checker.  Initially, you had to click a button to spell check your document. That has obviously changed dramatically. Now we see any mistakes we make as we type them (and can even fix them automatically).

That’s what we were thinking when we introduced continuous analysis in our plug-in tools and our source viewer for command-line tools, Klocwork Desktop.

Here’s the spell checker equivalent for source code analysis:











The above screenshot is from our Visual Studio plug-in.

When you open or save a file, the analysis runs in the background. A bug marker in the left gutter and a squiggly line, in the true spirit of the spell checker, clearly marks the detected issue.

Find ‘em and fix’em while you work.


Developer productivity thrown out the door

Posted by Alen Zukich   June 2nd, 2009

I deal with many organizations that deploy the Klocwork software to the desktop so that developers can use our tools to help them find and fix bugs in their code.  The message is simple, fix your bugs before you check in your code.  Many of the organizations I deal with have a mismatch of environments and tools.  In the world of writing code it is not uncommon to find developers using Emacs, Vim, Visual Studio, Eclipse or any number of IDEs/text editors.  Nothing wrong with this, although it doesn’t offer a clean, repeatable environment but it does work.

Recently I keep running into situations where productivity seems to be thrown out the door.  Not only were the developers a mix of many (and I mean many) development environments but they made the decision to code on a platform that they do not compile on. They would write code in Windows or Linux then store their code in a central repository or some sort (in one case it was just NFS), then ssh to a different Linux machine and run the compiler on the code.  If the code fails to compile, look at that syntax error and go back to your other machine to navigate to the line of code and figure out the error.  Rinse and repeat.  Wow…