LoC is a dumb metric for functions
theaxolot.wordpress.com
LoC is a dumb metric for functions
1–10 of 66 posts
Re: LoC is a dumb metric for functions
#2LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this.
Knowing At a high level what needed to happen to accomplish what the code did, I know for a fact it could have and should have been broken down more. However, because of the complexity of what he wrote, no one had the patience to go through it. When he left, the code got thrown away.
While 10 LOC vs 50 LOC doesn’t matter, when commas enter the number, it’s a safe bet that things have gone off the rails.
Re: LoC is a dumb metric for functions
#3>Use your judgment, and don’t be bullied by people who prescribe specific line numbers.
Ironic way to end an article that repeatedly belittles the target audience.
Re: LoC is a dumb metric for functions
#4LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this. Knowing At a high level what needed to happen to accomplish what the code did, I know for a f…
Seems like the article missed an opportunity to talk about testing and MC/DC coverage. I don’t care if the PR is long or short, just show me that you have meaningfully tested how each branch can be reached with the full range of values and behaves correctly. Unit testing is easier with well chosen interfaces and worse without them, regardless of LOC.
Re: LoC is a dumb metric for functions
#5LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this. Knowing At a high level what needed to happen to accomplish what the code did, I know for a f…
>When he left, the code got thrown away.
Why even merging his code at first place. He was intern so i assume whatever he was working on was not mission critical.
Re: LoC is a dumb metric for functions
#6LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this. Knowing At a high level what needed to happen to accomplish what the code did, I know for a f…
>When he left, the code got thrown away. Why even merging his code at first place. He was intern so i assume whatever he was working on was not mission critical.
They were one-off projects where he was the sole dev, not part of a larger project. While not mission critical, the 1k line Perl script was helpful at the time. When we ran into a specific issue it allowed for recovery in minutes vs hours. We eventually added safeguards which prevented the issue from happening in the first place.
Re: LoC is a dumb metric for functions
#7For a longer, more detailed take on this see:
https://www.youtube.com/watch?v=bmSAYlu0NcY
which is for the book:
https://www.goodreads.com/book/show/39996759-a-philosophy-of...
Re: LoC is a dumb metric for functions
#8LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this. Knowing At a high level what needed to happen to accomplish what the code did, I know for a f…
> While 10 LOC vs 50 LOC doesn’t matter, when commas enter the number, it’s a safe bet that things have gone off the rails.
There are times when even a 1,000 LOC function is the better solution. The best example I can think of involve a switch statement with a very high branch factor (e.g., 100), where the individual cases are too simple to break out into separate functions. Something like the core loop of an interpreter will easily become a several-thousand line function.
Re: LoC is a dumb metric for functions
#9LOC is often a rough approximation for complexity. We once had an intern who made some useful things, but he didn’t know how to break anything down. One of them was a 1,000 line perl all as one function. I asked if it could be broken down into something more maintainable and he said no. There were several projects like this. Knowing At a high level what needed to happen to accomplish what the code did, I know for a f…
> While 10 LOC vs 50 LOC doesn’t matter, when commas enter the number, it’s a safe bet that things have gone off the rails. There are times when even a 1,000 LOC function is the better solution. The best example I can think of involve a switch statement with a very high branch factor (e.g., 100), where the individual cases are too simple to break out into separate functions. Something like the core loop of an interpr…
Cyclomatic complexity is not equal to LOC and cyclomatic complexity of a switch can be seen as adding just 1 to its enclosing function. Either way, LOC is still not a great metric while cyclomatic complexity approaches a better one.
In my experience, there are very few places where something can't be broken up to reduce cognitive overhead or maintainability. When a problem is solved in a way as to make it difficult to do then maybe it's better to approach the problem differently.
Re: LoC is a dumb metric for functions
#10The whole point of a rule-of-thumb is to be dumb. There are very few good reasons for a 500 loc func, and the code reviewer won't want to verify it's as simple as you claim. You could still have a 50 loc func that's overly complex, and they'll complain about complexity instead of length.
One consideration is that about 40 loc will comfortably fit in one code split, and it's nice if one func will fit in 1-2 splits. Past that length, no matter how simple it is, the reader will have to start jumping around for declarations. That might be ok at first, but at some point the ratio of offscreen to onscreen code gets too big.