trgroleau@CCGATE.HAC.COM wrote:
>
> All,
>
> It seems to me that this is largely an issue of style and
> readability. I've personally found that it is most helpful to make
> sure that a particular object does not occupy more than a screenful of
> space. There are several habits that I think help in this.
>
> One is to minimize your boxes so they take up less space on the
> screen. Change the box names so that they reflect the function that
> the box is performing (i.e. FORMULA becomes INCR INDEX or something
> similar) in some shorthand that is fairly understandable.
>
> Another thing that I always do is change the LOOP boxes to "No
> Icon" and make the loop control objects one color (orange). This way
> I can always see where my loops start and where they break or repeat.
> By using color code for the loops, I save a lot of screen space, while
> maintaining readability.
>
> In the same way I color code any object that fetches or sets a
> global variable. In this way I can easily see where I am depending on
> a global variable in my code and have an idea later of what the
> reference in the middle of a formula was.
>
> Then there is looking for logical places to combine a string of
> boxes into a User Object. If there is a thread where it is pretty
> clear that there is one input and several boxes later, one output,
> that's a good candidate for a User Object - named to reflect the
> overall function of that string of boxes.
>
> Lastly there is the very handy capability of combining several
> formulae into one formula box rather than incremental operations
> taking several boxes. This is not always best, such as in debugging
> an algorithm, but is very useful to program readability once the
> algorithm is working. Again, the box needs to be named to reflect the
> function performed by the set of formula.
>
> These are just some ideas, but there is a real need to visually
> structure a VEE program, or maintainability goes right down the drain.
> I have spent several weeks trying to understand another programmer's
> code, largely because it ran off the screen in so many directions - so
> I started doing some of these things of necessity. This has also been
> a perceived shortfall of VEE (that is becomes true spaghetti code real
> fast), but can be overcome if some effort is expended on structure,
> especially on a large project with several programmers. Whatever
> conventions your project decides to use, the team needs to agree on
> them an see that they are used.
>
> That's my 2 cents worth
>
> Thomas Groleau
> Tucson, Arizona
>
> ______________________________ Reply Separator
Hi everybody,
I would like to say that I agree wholly with Thomas.
In fact we have in our project a Programmers Manual for VEE in order that every
programmer uses the same conventions. It is very important the colour code to
perform a quickly overview of some VEE code.
I suggested here, time before, that VEE could have a set of colour code
different for different objects. I am thinking of the windows colour set of
Windows 95 (for example). If the user wants, he has a default mode (that could
be the current colour mode) or a set of colours and fonts windows. This could be
translated to VEE, 'I think' with a low effort.
The other part is the documentation. Of course, for large projects (as our
projects are) it is very important to have a good documentation of the code. I
think VEE (that is a very good tool) need to improve this item.
Regards,
--
______________________________________________________
Juan Carlos Martin
E-mail : jcmar@mdr.indra-espacio.es
Phone : 34-91-3963995
Fax : 34-91-3963912
Earth Stations Department
INDRA ESPACIO / MADRID /SPAIN
>
> All,
>
> It seems to me that this is largely an issue of style and
> readability. I've personally found that it is most helpful to make
> sure that a particular object does not occupy more than a screenful of
> space. There are several habits that I think help in this.
>
> One is to minimize your boxes so they take up less space on the
> screen. Change the box names so that they reflect the function that
> the box is performing (i.e. FORMULA becomes INCR INDEX or something
> similar) in some shorthand that is fairly understandable.
>
> Another thing that I always do is change the LOOP boxes to "No
> Icon" and make the loop control objects one color (orange). This way
> I can always see where my loops start and where they break or repeat.
> By using color code for the loops, I save a lot of screen space, while
> maintaining readability.
>
> In the same way I color code any object that fetches or sets a
> global variable. In this way I can easily see where I am depending on
> a global variable in my code and have an idea later of what the
> reference in the middle of a formula was.
>
> Then there is looking for logical places to combine a string of
> boxes into a User Object. If there is a thread where it is pretty
> clear that there is one input and several boxes later, one output,
> that's a good candidate for a User Object - named to reflect the
> overall function of that string of boxes.
>
> Lastly there is the very handy capability of combining several
> formulae into one formula box rather than incremental operations
> taking several boxes. This is not always best, such as in debugging
> an algorithm, but is very useful to program readability once the
> algorithm is working. Again, the box needs to be named to reflect the
> function performed by the set of formula.
>
> These are just some ideas, but there is a real need to visually
> structure a VEE program, or maintainability goes right down the drain.
> I have spent several weeks trying to understand another programmer's
> code, largely because it ran off the screen in so many directions - so
> I started doing some of these things of necessity. This has also been
> a perceived shortfall of VEE (that is becomes true spaghetti code real
> fast), but can be overcome if some effort is expended on structure,
> especially on a large project with several programmers. Whatever
> conventions your project decides to use, the team needs to agree on
> them an see that they are used.
>
> That's my 2 cents worth
>
> Thomas Groleau
> Tucson, Arizona
>
> ______________________________ Reply Separator
Hi everybody,
I would like to say that I agree wholly with Thomas.
In fact we have in our project a Programmers Manual for VEE in order that every
programmer uses the same conventions. It is very important the colour code to
perform a quickly overview of some VEE code.
I suggested here, time before, that VEE could have a set of colour code
different for different objects. I am thinking of the windows colour set of
Windows 95 (for example). If the user wants, he has a default mode (that could
be the current colour mode) or a set of colours and fonts windows. This could be
translated to VEE, 'I think' with a low effort.
The other part is the documentation. Of course, for large projects (as our
projects are) it is very important to have a good documentation of the code. I
think VEE (that is a very good tool) need to improve this item.
Regards,
--
______________________________________________________
Juan Carlos Martin
E-mail : jcmar@mdr.indra-espacio.es
Phone : 34-91-3963995
Fax : 34-91-3963912
Earth Stations Department
INDRA ESPACIO / MADRID /SPAIN
window - even with using many user objects.
Sometimes, I will have a need to connect a program flow line or a data
line to an object that is outside of the active viewing area.
Presently, to do this I create a "do nothing" object like a label,
attach the subject line to it, then move the new object to the area
where the target object is, connect to the target object, then delete
the do nothing object.
Surely, there is a better way.
Can anyone help?