From: arne@vajhoej.dk
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 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
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
