AnsweredAssumed Answered

More metrics

Question asked by aufenanger on Jul 20, 1999
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
> ------------------------------------------------------------

Outcomes