AnsweredAssumed Answered

Comments

Question asked by VRFuser on Mar 9, 1996
from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to:   VRf
date: Sunday, 10 March 1996 1259 MST

Hello All:

A French HP sales rep was asking me for guidelines on developing VEE programs;
all I had was a section from the VEE tutorial that I expanded a little, but
I wanted to send more.

Obviously few people in the factory actually build large applications -- the
lab team spends their time trying to get things to work, support spends their
time putting out fires -- and so it seems that end-users would have the
best understanding of such issues and I would like to get any comments.
I am including my current document as a starting point.

Please post responses to the reflector rather than myself as I would like
to see if we can get some cross-comments.  I am rather busy right now (new
product introductions!) so I may not be able to respond personally in detail.

BTW (by the way), thanks for the responses on the website survey.  I will do
what I can to get a better service but so far I have been wading through a
field of bureaucratic obstacles ... none significant so far but I suspect they
may become worse.  The responses should help me quite a bit.

There is a marvelous novel by Vernor Vinge called MAROONED IN REAL TIME --
likely one of the few novels ever written that is both an excellent
science-fiction novel and a murder mystery -- in which, in the distant future,
the hero complains about "these information-systems types -- they say they can
do anything, but when you want to do something they tell you it's impossible!"

[%%] regards -- gvg



  • VEE PROGRAMMING PRINCIPLES 

    * While a number of VEE programming principles have been outlined in earlier
    chapters, it's useful before actually cooking up some demos to list them in
    detail.

    The "right" way to make a VEE program -- if there really is a "right" way --
    has not yet been agreed upon by any means; however, there are certain apparent
    rules of thumb that can help the aspiring VEE programmer to write a VEE
    program that is efficient and maintainable:

    % Document your programs reasonably.  Use a NotePad object in the top-level
       program and in each UserObject or UserFunction to describe program
       operation at the depth of abstration corresponding to the program level.

       The NotePad in the top-level program should include revision numbers and
       revision dates, along with a quick description of what revisions occurred
       at those dates.

       You can also use the "Show Description" field of an object like a
       Formula box to provide a detailed explanation of the actions of that
       object.  However, you should make a reference to such descriptions in
       the NotePad, since users rarely exploit this feature and so they might
       otherwise go unnoticed.

    % Process data in array formats whenever possible.  VEE allows most
       operations to be performed on arrays just as they are on scalar values;
       array processing allows for much more compact and faster VEE programs.
       See the chapter on array math for details.

    % Try to consolidate operations into as few blocks as possible, using the
       most powerful objects at your disposal.  The Formula box is particularly
       useful in this regard; a little ingenuity -- the Triadic operator comes
       in handy -- can allow the Formula box to perform powerful actions in a
       single formula.

    % Encapsulate wiring in UserObjects.  Rather than have a rat's nest of
       wiring cluttering up your program, encapsulate blocks of functions in
       UserObjects whenever possible.

    % If you change the title of an object, make sure you give some hint as
       to what kind of object it is.  For example, if you have a UserObject and
       want to name it "BuildData", you might instead name it "U_BuildData", with
       the "U" signifying that the object is in fact a UserObject.

    % Similarly, when defining pins for UserObjects, Formula boxes, and the like,
       try to give the pins meaningful names.

    % Avoid use of Gates and Sample-&-Hold objects.  There may be times when
       they are necessary, but they're basically crutches around VEE propagation
       engine limitations.  A good understanding of VEE will allow you to limit
       their use.

    % Design some flexibility into your user interface; make sure that your
       display objects can accommodate larger fonts that may occur on different
       systems, and allow for the fact that color selections may also be slightly
       different on multiple platforms or display systems.

    % If you are designing your program for multiple platforms, make sure that
       you design your VEE interface to fit into the smallest one ... for example.
       if your target platform includes systems with 640x480 resolution displays,
       make sure that the user interface is no bigger than 640x480.

    % For the design of large programs it is useful to modularize your program
       into sets of UserFunctions that can be independently developed and
       tested and then merged into a target application.  Make sure, however,
       that you develop guidelines for your developers so that they have an
       agreed-upon set of global variables, naming conventions, and error
       handling schemes so that the system works cleanly on final assembly.

    [%%]

  • Outcomes