Dear Juan,
Note to point 3:
I mean every object. I think of the properties of an formula object, not of
the description of the objects. I don't feel, that it helps if I have to
open something to get some understanding of the program.
Note to point 6:
I think in general you should avoid user objects. If you use the code only
once you don't have any problems. But normally programmers copy user
objects. You have the same code twice in your program. Now it happens that
there is a bug in this code. Usually they repair it in the first user object
and they forget to repair it in the second. That causes a lot of irritation.
Note to point 7:
I agree. But still the program is much easier to read with Start and exit.
Note to
>I agree with you that lines of code is not a good indicator about the
goodness
>of the design. But it is a raw indicator about the possible effort. Maybe
in
>case of VEE should be better to say "objects" instead of "lines of code".
Maybe
>the if a library has 1000 objects do not say nothing, but I am sure that if
1000
>objects are included only in 3 UO or UF means that it is a bad design and
an
>unmaintainable application.
In our company one function has to fit on the screen without scroll bars. So
we will never have 300 objects in one user function.
Best regards
Barbara
------------------------------------------------------------
Somatec B. Aufenanger & M. Bernhardt
Jagdweg 7a
D-82041 Deisenhofen
Telefon : (089) 613 984 91
Fax. : (089) 613 981 23
Email : Aufenanger@somatec.de
homepage : http://www.somatec.com
------------------------------------------------------------
-----Original Message-----
From: Juan C. Martin [mailto:jcmar@mdr.indra-espacio.es]
Sent: Wednesday, July 21, 1999 9:53 AM
To: B Aufenanger
Cc: VEE Usergroup (E-Mail)
Subject: Re: More metrics
Dear Barbara,
I agree with the most part of your point of view, although not all. Let me
comment your very interesting points about metrics (well, maybe better to
say
here design).
B Aufenanger wrote:
>
> Dear Juan,
>
> I don't believe that you can measure a "good designed" program in lines of
> code. If another person than the developer can see the code and can
> understand it just in looking at it that's a good designed program. A
> program like this will be very cheap in development, in testing, in
> integration an in using parts of the program in the next project. If there
> is a problem with the first programmer you can switch to the next on
without
> any loose of manpower. There are only some very basic rules to follow:
>
> 1. Split the problem into smaller problems and handle everything
> belonging to this in an own library. For example handle each instrument in
> it's own library.
Agree, we already do it.
> 2. Build a library in a way that you can test it without the rest of
> the program.
Agree, we already do it.
> 3. Use documentation for every object.
Agree, we already do it (I suppose it means every User Object or User
Function
and not at formula object, for example). One of my suggestion for VEE is to
improve the ways programs are documented. Currently the note pad editor is
very
bad.
> 4. Use colors.
Agree, we already do it. Another VEE suggestion is that set of objects of
the
same family (UO or UF, or displays/indicators are two different examples)
could
be generated when designing with specific colour that could be defined into
a
Company. It should be a good way to meet with point 8 (part of it).
> 5. Don't build larger functions. Take care that it fits on the
screen.
Agree, we do it.
> 6. Avoid user objects. You never know if you can use this
functionality
> once again.
I don't agree. I think it depends on the design. take into account that UFs
have
a default: they are flat at design level meanwhile UOs are structured (one
into
other) and it is more easy to follow from the explorer. UOs are designed for
specific functionality, UFs are designed for generic funtionality.
If all are UF you could lose the traze of the control/data flow: teh
structure
of the program.
> 7. Use Start and ExitUserObjects to determine the program flow in
every
> function.
I don't agree. It is true in version 3.x or 4.x but not in version 5.x.
START
object should not used (if you are not making debugging) in VEE 5.x. there
are
other ways to determine the flow.
> 8. Make sure that all your programmers in the company use the same
> programming rules.
Fully agree. But first it is necessary to get that rules. I would be happy
to
hear about them (maybe by exchanging).
>
> You can measure quality of a program, when you change test affords on the
> same hardware. When the changes are done in one ore two ours it's a good
> designed program. When it takes weeks it's a bad designed program.
However I think it is necessary more. If we take only this into account, it
is
the same for any other programing language: It is not possible to perform
good
measurements. Is it true?
We use extensively VEE in our company. I think of metric (of course by using
automatic tools) maybe they will not show us all that we would like to know
to
improve our design and of course, reduce our costs. But maybe it will say us
a
part of it or it will provide us clues to think in ways to improve.
But first is to think what we want to measure. This is directly related to
my
before E-mail.
I agree with you that lines of code is not a good indicator about the
goodness
of the design. But it is a raw indicator about the possible effort. Maybe in
case of VEE should be better to say "objects" instead of "lines of code".
Maybe
the if a library has 1000 objects do not say nothing, but I am sure that if
1000
objects are included only in 3 UO or UF means that it is a bad design and an
unmaintainable application.
Metric needs to be coherent, used for several similar proyects and
interpreted
in terms of quatilty from obtained quantity results.
In any case thanks for your suggestions.
>
> I always think:
>
> "The intellect of a programmer is inversely proportional to the lines of
> code a programmer needs to solve a problem.":-)
>
> Best regards
> Barbara Aufenanger
> ------------------------------------------------------------
> Somatec B. Aufenanger & M. Bernhardt
> Jagdweg 7a
> D-82041 Deisenhofen
>
> Telefon : (089) 613 984 91
> Fax. : (089) 613 981 23
> Email : Aufenanger@somatec.de
> homepage : http://www.somatec.com
> ------------------------------------------------------------
Note to point 3:
I mean every object. I think of the properties of an formula object, not of
the description of the objects. I don't feel, that it helps if I have to
open something to get some understanding of the program.
Note to point 6:
I think in general you should avoid user objects. If you use the code only
once you don't have any problems. But normally programmers copy user
objects. You have the same code twice in your program. Now it happens that
there is a bug in this code. Usually they repair it in the first user object
and they forget to repair it in the second. That causes a lot of irritation.
Note to point 7:
I agree. But still the program is much easier to read with Start and exit.
Note to
>I agree with you that lines of code is not a good indicator about the
goodness
>of the design. But it is a raw indicator about the possible effort. Maybe
in
>case of VEE should be better to say "objects" instead of "lines of code".
Maybe
>the if a library has 1000 objects do not say nothing, but I am sure that if
1000
>objects are included only in 3 UO or UF means that it is a bad design and
an
>unmaintainable application.
In our company one function has to fit on the screen without scroll bars. So
we will never have 300 objects in one user function.
Best regards
Barbara
------------------------------------------------------------
Somatec B. Aufenanger & M. Bernhardt
Jagdweg 7a
D-82041 Deisenhofen
Telefon : (089) 613 984 91
Fax. : (089) 613 981 23
Email : Aufenanger@somatec.de
homepage : http://www.somatec.com
------------------------------------------------------------
-----Original Message-----
From: Juan C. Martin [mailto:jcmar@mdr.indra-espacio.es]
Sent: Wednesday, July 21, 1999 9:53 AM
To: B Aufenanger
Cc: VEE Usergroup (E-Mail)
Subject: Re: More metrics
Dear Barbara,
I agree with the most part of your point of view, although not all. Let me
comment your very interesting points about metrics (well, maybe better to
say
here design).
B Aufenanger wrote:
>
> Dear Juan,
>
> I don't believe that you can measure a "good designed" program in lines of
> code. If another person than the developer can see the code and can
> understand it just in looking at it that's a good designed program. A
> program like this will be very cheap in development, in testing, in
> integration an in using parts of the program in the next project. If there
> is a problem with the first programmer you can switch to the next on
without
> any loose of manpower. There are only some very basic rules to follow:
>
> 1. Split the problem into smaller problems and handle everything
> belonging to this in an own library. For example handle each instrument in
> it's own library.
Agree, we already do it.
> 2. Build a library in a way that you can test it without the rest of
> the program.
Agree, we already do it.
> 3. Use documentation for every object.
Agree, we already do it (I suppose it means every User Object or User
Function
and not at formula object, for example). One of my suggestion for VEE is to
improve the ways programs are documented. Currently the note pad editor is
very
bad.
> 4. Use colors.
Agree, we already do it. Another VEE suggestion is that set of objects of
the
same family (UO or UF, or displays/indicators are two different examples)
could
be generated when designing with specific colour that could be defined into
a
Company. It should be a good way to meet with point 8 (part of it).
> 5. Don't build larger functions. Take care that it fits on the
screen.
Agree, we do it.
> 6. Avoid user objects. You never know if you can use this
functionality
> once again.
I don't agree. I think it depends on the design. take into account that UFs
have
a default: they are flat at design level meanwhile UOs are structured (one
into
other) and it is more easy to follow from the explorer. UOs are designed for
specific functionality, UFs are designed for generic funtionality.
If all are UF you could lose the traze of the control/data flow: teh
structure
of the program.
> 7. Use Start and ExitUserObjects to determine the program flow in
every
> function.
I don't agree. It is true in version 3.x or 4.x but not in version 5.x.
START
object should not used (if you are not making debugging) in VEE 5.x. there
are
other ways to determine the flow.
> 8. Make sure that all your programmers in the company use the same
> programming rules.
Fully agree. But first it is necessary to get that rules. I would be happy
to
hear about them (maybe by exchanging).
>
> You can measure quality of a program, when you change test affords on the
> same hardware. When the changes are done in one ore two ours it's a good
> designed program. When it takes weeks it's a bad designed program.
However I think it is necessary more. If we take only this into account, it
is
the same for any other programing language: It is not possible to perform
good
measurements. Is it true?
We use extensively VEE in our company. I think of metric (of course by using
automatic tools) maybe they will not show us all that we would like to know
to
improve our design and of course, reduce our costs. But maybe it will say us
a
part of it or it will provide us clues to think in ways to improve.
But first is to think what we want to measure. This is directly related to
my
before E-mail.
I agree with you that lines of code is not a good indicator about the
goodness
of the design. But it is a raw indicator about the possible effort. Maybe in
case of VEE should be better to say "objects" instead of "lines of code".
Maybe
the if a library has 1000 objects do not say nothing, but I am sure that if
1000
objects are included only in 3 UO or UF means that it is a bad design and an
unmaintainable application.
Metric needs to be coherent, used for several similar proyects and
interpreted
in terms of quatilty from obtained quantity results.
In any case thanks for your suggestions.
>
> I always think:
>
> "The intellect of a programmer is inversely proportional to the lines of
> code a programmer needs to solve a problem.":-)
>
> Best regards
> Barbara Aufenanger
> ------------------------------------------------------------
> Somatec B. Aufenanger & M. Bernhardt
> Jagdweg 7a
> D-82041 Deisenhofen
>
> Telefon : (089) 613 984 91
> Fax. : (089) 613 981 23
> Email : Aufenanger@somatec.de
> homepage : http://www.somatec.com
> ------------------------------------------------------------
Hi VEE users,
I am still thinking about VEE metrics. Even before starting to discuss about
metrics, maybe should be interesting to clarify when an VEE application is a
"good design" and when it is a "big application" (in the sense of size).
Maybe answers to some questions could help me/us to understand the scope of the
subject.
1. When is considered a VEE application as big/medium/small size?
a) Does it depend on the number of UserObjects+UserFunctions of all the
associated programs/libraries of the application?
b) Does it depend on the number of the programs/libraries itself?
c) Does it depend on the total number of VEE lines, or the VEE files size in
kBytes?
One approach could be point a. For example: more than 400 UO+UF could be
considered as big application. between 100 and 400 UO+UF could be medium
application and less than 100 small. Of course, there are two ways to reach
these data. For example, an application with 10 programs+libraries with 40 UO+UF
each one, that is 400 UO+UF as total, or 40 programs+libraries with 10 UO+UF
each one, that is the same 400. This is related to complexity and modularity.
In any case, all these items could be measured. It suggests me that number of
program/libraries versus number of UO+UF could be a good ratio.
Of course, it could be not enough, because it should depend also on the size of
the UOs or UFs. But this guide us to the next point.
2. When a VEE application has been well designed.
a) Does it depends on the number of UO+UF per library.
b) Does it depend on the number of objects per UO or UFs
c) Does it depend on how deep is the UO tree on the VEE explorer.
d) Does it depends on the cross calling between UO and UF, within or without
from the same library.
e) Does it depends on the number of explicit number of in/out variables of UO
and UF, or the number if implicit in/our variables (global variables).
As can be seen, point a) it related to the application size and it is also
related to its design. I think one VEE library with more than 100 UO+UF could be
considered as NOT a good design, even in the case of each UO or UF of it only
has a few objects (8, for example).
But what could be considered as a good design: 20 UO+UF per library/program? and
what about 40?
It is important because it is easy to measure and could be quantified.
Of course, the number of objects into a library should indicate us how good
design is a VEE file. What is a good design, 10 objects per UO or UF? or 20 or
30?
Of course, the goodness of design depends also of the type of objects. For
example it is not the same a "sequencer" than a "integer constant". It is not
the same a "formula" than an "OK". That let us to think about performing a
measurement weighted depending on the type of the objects involved. This is not
so easy to measure.
In any case, this is other ratio that could be measured: number of objects per
UO or UF.
How deep is my design could also define me the goodness of it. For example, 9
steps of UO into other UO should suggest us a bad design. But What is a good
design, 5 as maximum? In any case could be also measured easily.
Point c) and d) are also important but I am not able to suggest any hypothesis.
And the same with external functions associated to the application (ActiveX,
DDL, etc.).
This is close related to the term "complexity". And for my point of view, this
is more difficult to measure.
Any suggestion?