Re: How have code analysis tools changed the way you work?

From: David (FlyLikeAnEagle_at_United.Com)
Date: 06/10/04 

Date: Thu, 10 Jun 2004 02:39:26 GMT

On Wed, 9 Jun 2004 23:15:43 UTC, esther@bitranch.com (Esther Schindler)
wrote:

> I'm a journalist, working on an article for Software Development Times
> (http://www.sdtimes.com). Instead of writing Yet Another Article about
> what code analysis tools can do for you (yawn), I'm looking at the
> social/business side of such tools. In particular: how do you use
> them, and how have they changed the way you create apps... for good or
> ill?
>
> The obvious analogy is spell checkers. We take them for granted, now,
> but those of us who are old enough to remember when a spell-checker
> was a $75 add-in tool remember the revelation. Wow, something that'd
> take care of my spelling for me! The certainty that your business
> correspondence wouldn't look unprofessional made it easier for some
> people to write. However, a spell checker would mark "to," "too," and
> "two" as equally correctly spelled, even if it was the wrong word.
> And, as with all tools, some people assume that the tool will take
> care of the "thinking."
>
> So, too, with code analysis tools. They undoubtably make a lot of
> development tasks easier, but they also make things *different*.
> Whether you use code analysis tools for your own personal use, or as
> part of a team... how have these changed you? Give me a
> before-and-after.
>
> I'll check back here, but if I'm to quote you I'll need your full
> name, title, and company affiliation. So it's also cool with me if you
> contact me personally at esther@bitranch.com.
>
> Esther Schindler
> contributing editor, SD Times

  Hello Esther,

  I agree with Alan that the compiler/lint integration has made some
of the programming tasks a bit easier. Another big plus has been
for the Syntax Directed Editors, IDEs, and a few of the CASE tools.
I've written various helper apps, like code coverage tools, and
a few tools to gather documentation direct from the source code.
Some of these work well and others don't.

  I program at the application and embedded levels for mission
critical uses. Code analysis tools have helped me insure that
the code paths get tested, stressed, and documented. I suppose
performance counters and such may also find their way into your
paper.

  The general use of many of these tools has helped me find flaws
earlier in the development process. I try to write the best code
up front, after a good design, but we all miss things once in a
while, especially when inheriting a large project. It is important
to be able to understand what the system is doing.

  In general, I think that most code analysis tools get wrapped
into other forms before being presented to the user. These hidden
uses may not seem important, but computing is about the details.
A good syntax directed editor, lint-like error recognition, and
an optimized code generation are all things that help make the
development process better but aren't usually seen. The casual
user sees the magic and perhaps doesn't understand that the
code is being understood (analyzed) at many different levels.
It helps develop and check other concepts like provide development
hints, verify code completeness and correctness, and provide
an understanding that can enable a proper reordering (optimization)
for the target machine.

  David
  -- still using OS/2 as my primary home machine --

P.S. I've always enjoyed your articles. Thank you.