Time to understand a program by LOC

Question

Are there any broad, overgeneralized and mostly useless rules about how long it will take to understand a program based on the number of LOC (lines of code)?

(I understand any rules will be broad, overgeneralized and mostly useless. That's fine.)

(The language in question is Delphi, but that shouldn't matter because I'm looking for broad, overgeneralized and mostly useless rules.)

Answer 1

Some papers concerning peer code review say that it should be somewhere between 100 and 400 lines of code per hour.

Answer 2

It's not the number of LOC that determines how long it takes to understand a program, it's more the complexity.

If my program had 100,000 lines of print statements, I think the program is pretty clear to understand. However if I had a program with for-loops nested ten deep, I think that will take far longer to understand.

Cyclomatic complexity can give a ROUGH indication of how hard the code is to understand, and can signal some other warning flags as well about your code.

Answer 3

I have the theory that it's O(n²) (because you have to understand each line in conjunction with every other line).

But, as usual when using big-o notation to get an actual numeric value, this answer is broad, overgeneralized and mostly useless.

Answer 4

You cannot google this because there will be a different approximate number for each individual person programming in a specific language.

You are trying to write the Drake's Equation for program writing.

This is what I mean.

About program writers.

• each person has a different style of writing and commenting code
• every programming language has different nuances and readability
• algorithms can be implemented in many ways even in the same language
• data structures used by different people tend to be quite varied
• the decision of how code is distributed over source files also changes with personal taste

Moving to the person reading the code.

• the familiarity of the person with the language matters
• familiarity to the algorithms and data structure patterns used matters
• amount of information context that the person can retain at a time matters

Shifting focus to the environment, things that matter would be.

• the amount of distraction (both for the programmer and the person trying to read the program)
• nearness to code release time for the programmer
• pending activities and motivation on the part of the reader
• proximity of popular events (vacations, sports events, movie release dates!)

Answer 5

Code review metrics (which is not the same thing, but nearly comparable) put the number in the range of approximately 50-100 LoC per hour, for an experienced code reviewer.

This of course also depends on what they're looking for in the review, language, complexity, familiarity, etc.... But that might give you a general overgeneralization anyway.

Answer 6

I'm looking for broad, overgeneralized and mostly useless rules.

Sounds to me like you're just trying to find a way to estimate time it will take to learn a new codebase to management or something. In that case, find a code snippet online, and time how long it takes you to understand it. Divide that by the number of lines in the snippet. Add some padding. Bam! There's your rule.

Answer 7

Look at the COCOMO equations. They contain broad, overgeneralized and mostly useless rules based on Source Lines of Code.

Answer 8

Apart from "how complicated is the program?", other variables include things like "how well do you understand it?" and "how well do you understand other things, such as the program's functional specification?"

When I start to work with a new program, I try to understand as little of it as possible! Specifically I try to:

• Understand the functional specification of the change that someone wants me to make (if nobody wanted me to change the program then I wouldn't need to understand it at all)

• Find and understand the smallest possible subset of the existing program, which will let me make that change without breaking any other, previous/existing functionality.