The LA Fox Developer Newsletter

May 1995

Out and About (Con't from page 4)

some of the vendors who have signed on to the

“Codebook Compliant/Compatible” methodologies

mentioned in the April edition of the LA Fox Devel-

oper. These companies include Cascade Interactive

Designs (CapCon), Great Elk (contact management

software), Hentzenwerke (FoxZen), Korenthal Asso-

ciates (PhDbase), MicroMega (FoxFire!) Neon

Software (FoxExpress), Performance Dynamics

(RAIDAR), and SBT Corporation (accounting soft-

ware).

To quote from their newsletter:

“There will be two types of Codebook 3.0 Certifica-

tion. If a product is certified as ‘Codebook Compli-

ant’, it will mean that it utilizes the methodologies,

class libraries, standard data dictionary extensions,

and general architecture contained in Codebook. A

‘Codebook Compatible’ product will include in its

documentation the method for integrating the prod-

uct into a Codebook application and will also hook

directly into the Codebook extended data dictionary.

Each product will be evaluated and certified by Flash

and will bear an apprcpriate logo.”

This may be, as mentioned in last month’s LA Devel-

oper, a good turn of events. On the other hand, I

can’t help but think about Tom Rettig’s comment (at

last month’s meeting) on how it might be too soon

yet to embrace a single methodology. We’ll have to

wait and see on this one.

Randy Brown, co-author with Lisa Slater on FoxPro

MAChete, has joined the Microsoft team as project

manager for FoxPro Mac. Bill Anderson, one of our

members, knows a little more about him. According

to Bill, “Well, he’s been one of the few Mac consult-

ants for as long as I can remember. He’s extremely

knowledgeable on FoxPro. I think he’s been a

speaker at every DevCon, certainly most of them.

He’s one bright guy and will be a real asset to

Microsoft (IMO).”

Also from Bill Anderson, “The latest on dDay —

Borland, SBT and Neon Software has signed up for

booths, with Microsoft soon to follow. Speakers —

Currently slated are Ken Levy, Paul Heiser, Tom

Rettig, Mike Feltman. Borland will speak about

dBase for Windows and Delphi. Microsoft will be

there but their plans have not been finalized yet.”

Candy Machine Interfaces

by Michael Cummings

Steve Maguire in his book “Writing Solid Code”

compared the candy machines at Microsoft to buggy

code. He said: “I’d plunk in my quarters, press 4 and

then 5 on the selection keypad, and watch in horror

as the machine spit out jalapeno flavored bubble

gum instead of the Grandma’s Peanut Butter Cookie

I thought I had asked for. Of course, the machine

was right and I was wrong - number 45 was the

gum. A quick look at the little sign by the cookie

would always verify my mistake: No. 21, 45 cents.”

How are these vending machines like buggy code?

The candy machine encouraged mistakes. People

would be thinking 45 cents as they entered the

selection codes. He suggested using an alphabetic

keypad instead, entirely preventing the “bug.”

Steve said that many of the standard C library

functions and functions modeled on them are just as

poorly thought out as those candy machines.

“getchar Gets an int, of Course”

“Programmers... can write code that appears to work

correctly even though it’s flawed. Its not until weeks

or months later that the code crashes unexpectedly

because, as in the sinking of the Titanic, a precise

series of improbable events takes place and leads to

disaster.”

The problem is that the design of the functions did

not lead “programmers to write correct code, [such

functions] lead the programmer to ignore the error

condition.”

This is not just a C language problem, the same

problem exists regardless of the language. I once

worked on a large project in Access and after sev-

eral months we found mysterious bugs in the sys-

tem. Mysterious, that is, until we found that one

progammer was routinely ignoring error return codes

from functions. His code assumed that everything

worked, so his program would be ‘walking wounded,’

unaware, for instance, that someone else had a

record locked. Worse yet, when the error value he

had not checked for was numeric, but his code

expected characters, the whole program crashed,

(Con't page 6)

Page 5