Re: Clair Grant on VMS code base

On 4/17/2025 1:58 PM, bill wrote:

On 4/17/2025 1:04 PM, Arne Vajhøj wrote:

On 4/17/2025 10:08 AM, bill wrote:

On 4/17/2025 8:56 AM, Arne Vajhøj wrote:

On 4/17/2025 8:50 AM, Simon Clubley wrote:

On 2025-04-17, bill <bill.gunshannon@gmail.com> wrote:

On 4/16/2025 9:29 PM, Dan Cross wrote:

Most modern code-counting tools _are_ language aware.  Whether
they do a better or worse job for each given language may be a
matter of debate, but most at least recognize different
languages and have some knowledge of their semantics.
>

I wonder how they would handle BASIC?  :-)
>
10 FOR X = 1 TO 10
20 PRINT X
30 NEXT X
>
10 FOR X = 1 TO 10:PRINT X:NEXT X
>
Is the snippet above one line of code or three?

>
3 lines of code.

>
Other replies cover what the tools actually does.
>
If we discuss what is the "right" answer, then I would
actually say 2.
>
for i := 1 to 10 do writeln(i)
>
for i := 1 to 10 do
    writeln(i)
>
for i := 1 to 10 do begin
    writeln(i)
end;
>
for i := 1 to 10 do
begin
    writeln(i)
end;
>
for(i = 1; i <= 10; i++) printf("%d\n", i);
>
for(i = 1; i <= 10; i++)
     printf("%d\n", i);
>
for(i = 1; i <= 10; i++) {
     printf("%d\n", i);
}
>
for(i = 1; i <= 10; i++)
{
     printf("%d\n", i);
}
>
I would say 2 for all.
>
And unless Basic next has some subtle functionality I am not
aware of then I would say 2 for Basic as well.

>
Interesting concept.  But the NEXT is a requirement of the
language, does take time to type and if it is left out does
require debugging to fix the problem.  So, if we are counting
lines in some attempt to determine the cost of writing and
maintaining the program it seems it would have to count as
a line.

>
Programming is more about thinking than about typing.
>
The thinking part is about adding two constructs:
- having i iterate from 1 to 10 => Basic FOR loop
- printing a line with i => Basic PRINT statement
>
The specific language syntax requirement and the developers
formatting preference is not a thinking problem (unless
the developer does not know the language well, but
that is a more general problem).
>
Which is why I consider it two.
>
But all this goes back to my original point. Counting
non-blank and non-comment lines is simple while trying to
count "right" end up in having to make dozens maybe
hundreds of decisions on how to count various constructs
in various languages. Several posts back I brought up
fluent style - not an easy one to count in my opinion.
>
If we instead of those few lines you provided took an entire
application and asked everybody here to count, then I would not
be surprised if everybody came up with a different number.
>
Which is why I have been talking about "right" answer and not
right answer.

 Once again, Arne, it seems in the end we actually agree.
LoC is probably not easily extracted accurately.  And
the actual value of that information is minimal if of any
value at all.

Counting non-blank and non-comment lines is easy. For
a small piece of code it can vary greatly with coding
style used. But if you look at large code bases written
by many different developers then the coding style
averages out.
Let us say that you have files with one million
file lines in. Counting non-blank and non-comment lines
return 761951. Asking 100 people to count "right" number
of lines give 100 different answers between 733887 and 745231.
Counting non-blank and non-comment lines gives an objective
result and is valid as a proxy for the code size.
Is it useful to have such a value for estimation?
Honestly I doubt it. It is not obvious to me that
estimating LOC (or FP) is more accurate than
estimating effort. I am not a big fan of
COCOMO and the like.
Is it useful to analyze what determines effort?
I think so.
Let us say that you have two approaches (could be
programming language, development methodology or
something else) and you based on historic data can
estimate effort for the two as:
effort = 2.5 * KLOC**1.2
effort = 3.5 * KLOC**1.1
Guess what - the optimal approach depend on the size
of the project.

All that really matters is:
Does the program work?
Does it do what it was intended to do?
Does it do it without errors?

There are some people that care about how much it cost
to produce.
:-)
Arne