Re: How have code analysis tools changed the way you work?
From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 06/12/04
- Next message: Edward G. Nilges: "Re: Aspiring highest-order programmer"
- Previous message: Willem: "Re: Engineers doing stupid things "just for fun"."
- In reply to: Esther Schindler: "Re: How have code analysis tools changed the way you work?"
- Next in thread: Edward G. Nilges: "Re: How have code analysis tools changed the way you work?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Jun 2004 05:43:58 -0700
esther@bitranch.com (Esther Schindler) wrote in message news:<cca0b7bb.0406111058.790608e1@posting.google.com>...
> spinoza1111@yahoo.com (Edward G. Nilges) wrote in message news:
> > Altogether too many "tools" are written under what I call the Sears
> > Craftsman illusion/metaphor, in which the programmer reasons that
> > programming is "just like" puttering around the wood shed on Saturday
> > afternoon after a visit to Sears to buy a tool that makes puttering
> > about the wood shed fun and rewarding.
>
> That is a marvelous analogy.
>
> > Because these tools are spun as replacing the need for thought,
> > because it is said that once the tool is acquired, we can now stop
> > thinking, thinking stops and the tool becomes responsible for ignored
> > bugs created by the tool itself.
>
> That's the heart of my concern. Going back to the spelling checker
> analogy, plenty of people (especially the less experienced or those
> who care less about getting-it-right) will run the utility and then
> apply the results without thought. They use the tool as an excuse to
> not-think rather than to think better.
>
> But I could sure use an example or two to back this up. Got any?
(1) When using yacc (a tool to generate a compiler) you need to
eradicate all error and warning messages, otherwise the generated
"parser" code will behave in an unpredictable fashion. In general,
don't ignore error messages.
(2) The translation of source code to another language is always
fraught with danger. If a Or b is transliterated from Pascal or Visual
Basic to C or Javascript a || b, and b is actually a call on a complex
method, b will not be evaluated in C or Javascript when a is true,
while in the legacy code it will. The end user may have consciously or
unconsciously relied on this fact.
(3) "Code transformation" tools do a poor job generally speaking on
comments formatted for readability, since they have no way of
determining how and in what way the original coder arranged the
comments for readability.
The original coder may have split a wordy comment on two lines:
a = b; Use b's value, but
if (a < 0) punt; if b is negative, then wing it
If this source code is rearranged so are the lines in the comment.
Wizards and tools are marketed as timesavers and thoughtsavers. But
the latter feature means that many opportunities for due diligence
during otherwise boring tasks are lost.
>
> Esther
- Next message: Edward G. Nilges: "Re: Aspiring highest-order programmer"
- Previous message: Willem: "Re: Engineers doing stupid things "just for fun"."
- In reply to: Esther Schindler: "Re: How have code analysis tools changed the way you work?"
- Next in thread: Edward G. Nilges: "Re: How have code analysis tools changed the way you work?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|