Most Read Latest News Blog Resources

Letters to the Editor: March 15, 2009




March 15, 2009 — 
In his column (“When 100% code coverage is not enough,” Feb. 5, page 24), Andrew Binstock indeed is correct that traditional code coverage measures address only instruction and/or the more demanding branches and path executions, without taking into account the numerous ways in which each can be executed. However, he misses the bigger, more important failings of white box structural code coverage metrics: They have nothing to do with whether the code is right, and since they reflect only what has been written, they are irrelevant for anything omitted from the code. To be meaningful, such coverage metrics must be taken in the context of adequate black box functional testing.

Robin F. Goldsmith, JD

 

Weak link
Regarding your News On Monday “Linkapalooza” item from Feb. 9: "Regular expression matching can be fast and simple."

This article re: NFA and DFA implementations of regexps has been discussed at length, including considerations from the core Perl team responsible for regexps.

I don't think they'd quite call it a troll, but they reason that Perl (and others) use an NFA rather than a DFA approach is because "while DFA engines have a very good worst case match time, they don't actually have too many other redeeming features," and, "So there will be classes of patterns that NFA will not do well, but on the other hand there are patterns that a DFA cannot do at all, which is less useful than doing them slowly."

See the start of the discussion here, and look here in particular (demerphq is, I believe, in charge of regexps in Perl).

Unfortunately the article comes up regularly and the rebuttals less frequently.

Tim Meadowcroft

 

Comments from the Web
Larry, I love how you end this ("Quality: You are gonna need it" March 1, page 33): "Quality is the route to productivity. If you need productivity, you need quality. Quality can be improved with a balanced emphasis on code production, testing and design. You’re gonna need all those things."
We are rabid about code quality at NCover. Bad products sap the morale of the programmers who have to get involved to fix them. It just sucks. Here is one thing that we have noticed: Most developers don't want to write bad code; they just plan for any other option...

Daniel Waldschmidt

 

[In regards to "Share Pointers: Yes/No fields aren't your friends, Feb. 4:] As a database programmer, I would disagree. In fact, I would say that the CQWP [Content Query Web Part] is not performing as it should and thus should be changed. In my humble opinion, data fields should reflect, as closely as possible, the data type stored within. You wouldn't use a varchar field to store timestamps, and you wouldn't use a decimal field to store integers. Why use an xxchar field to store bit values? I would humbly accept someone telling me that I'm wrong.

"Brian"


Related Search Term(s): testing


Share this link: http://www.sdtimes.com/link/33333
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG