Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LoC is a dumb metric for functions

theaxolot.wordpress.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: LoC is a dumb metric for functions

#11

Post by morshu9001 »

jcranmer wrote: post #8
al_borland wrote: post #2

LOC 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…

That's a special case

Re: LoC is a dumb metric for functions

#12

Post by fragmede »

morshu9001 wrote: post #10

The 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. Pa…

I wonder if there is a way to see how physical monitor quality and size improvements have led to more complicated code, nevermind moving off of punch cards.

Re: LoC is a dumb metric for functions

#13

Post by morshu9001 »

fragmede wrote: post #12
morshu9001 wrote: post #10

The 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. Pa…

I wonder if there is a way to see how physical monitor quality and size improvements have led to more complicated code, nevermind moving off of punch cards.

The type of monitor doesn't matter a whole lot because it's really limited by human eyesight. High-res monitor will enable rendering things tiny if you disable hi-dpi, but then it's unreadable. If you use a big 8K TV to display everything larger, you have to sit further away to comfortably view it. If you add more monitors, at some point it becomes too hard to look at so many things at once.

Personally, my setup has shown the same number of vim rows/cols on my 4K monitor vs my 1080p one (or whatever you call the 16:10 equivalents).

Re: LoC is a dumb metric for functions

#14

Post by klysm »

000ooo000 wrote: post #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.

Use your judgement, don’t be bullied by people who prescribe using your judgment.

Re: LoC is a dumb metric for functions

#16

Post by jandrewrogers »

Sometimes I write long functions because I do not have time to write a shorter function. Eventually, if I have time, I go back and refactor a much shorter and tidier version. While later versions may be somewhat more efficient computationally, it is mostly a no-op beyond the aesthetics.

What is the LoC for that function? The first implementation or the final rewrite? They express the same thing.

Re: LoC is a dumb metric for functions

#17

Post by schrodinger »

WillAdams wrote: post #7

For 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...

This needs more than just an upvote — that's one of the best software engineering books I've ever read!

Re: LoC is a dumb metric for functions

#18

Post by zdragnar »

imoverclocked wrote: post #9
jcranmer wrote: post #8

Earlier quoted context omitted.

> 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 t…

Higher cyclomatic complexity requires more lines (barring bad code style like writing an entire program on a single line).

The inverse is not always true, but often is.

Re: LoC is a dumb metric for functions

#19

Post by kqr »

jcranmer wrote: post #8
al_borland wrote: post #2

LOC 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…

I would argue an interpreter that needs 1,000 lines for its core loop is probably a complex piece of software, comparable to other 1000-line projects I've made.

Re: LoC is a dumb metric for functions

#20

Post by nine_k »

morshu9001 wrote: post #13
fragmede wrote: post #12

Earlier quoted context omitted.

I wonder if there is a way to see how physical monitor quality and size improvements have led to more complicated code, nevermind moving off of punch cards.

The type of monitor doesn't matter a whole lot because it's really limited by human eyesight. High-res monitor will enable rendering things tiny if you disable hi-dpi, but then it's unreadable. If you use a big 8K TV to display everything larger, you have to sit further away to comfortably view it. If you add more monitors, at some point it becomes too hard to look at so many things at once. Personally, my setup has…

The effective resolution of the eye should be an angular value. I'd say that the smallest comfortable size of text characters for me is about 1/8° wide. I see the width of my 14" FHD laptop screen at about 30°, so the full width contains about 240 characters. This is a large upgrade from 80 columns of VT220 or VGA, and almost twice as much as the densest VT220 mode of 132 columns.

My 28" 4K monitor is exactly like four 14" FHD screens put together. It offers me 480 columns (a bit fewer, because window borders and scroll bars of multiple windows).

So indeed, better screens allow me to see much more text than poorer screens of old. There is a limit, but definitely it was not reached 30-40 years ago yet.

Post reply on HN