FilePro and otrher languages

Fairlight fairlite at fairlite.com
Fri Jul 6 14:16:35 PDT 2018


On Fri, Jul 06, 2018 at 09:05:58PM +0000, Richard Kreiss via Filepro-list
thus spoke:
>
> What I have derived from the course so far is that the programmers who
> wrote and are upgrading filePro have masked many of issues that arise.

-And- created some in the bargain.

> For all of us non-programmers, filePro does a lot "under the hood".  Yes
> it is easy to get started and write some complex applications.  But keep
> in mind FP Tech's programming staff has made this all possible.

It honestly helps to think of fP less as a language, and more as a toolkit.
It keeps the blood pressure down.

> One other thing that the course instructor has mentioned constantly is
> "test and retest your code as you go along". It is easier to correct an
> issue in one section of code then track down the issue when a lot of code
> has been written.  Build on what you have stable.

Regression testing cannot be emphasised enough.  I know too many people who
'fix' one thing, and break seven others in the process, but never see it
because they don't re-test ___end-to-end___ after they make changes.

Devise a standard test harness (for automated scenarios, like reports, or
CGI context programs), or a standard test procedure.  Encompass all parts
of functionality in every order in which they may be executed.  Always test
the software using the complete set of test points, executed in the same
order.  (If you included all possible orders which could matter, including
cycling back around, you shouldn't miss anything.)

You can't just toss half-arsed tests at something and pray it's fine.  You
need to be -methodical-.  You also need to test -everything-, not just what
you thought you changed.  Especially in filePro, where two-character field
names as variables make it easy to screw something up elsewhere, this is
key.

mark->
-- 
Audio panton, cogito singularis.


More information about the Filepro-list mailing list