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

21–30 of 66 posts

Re: LoC is a dumb metric for functions

#21

Post by hu3 »

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…

> I asked if it could be broken down into something more maintainable and he said no.

This is something AI is good at. It could have shown the intern that it is indeed possible to break such function without wasting an hour of a seniors time.

Re: LoC is a dumb metric for functions

#22

Post by [deleted] »

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…

[deleted]

Re: LoC is a dumb metric for functions

#23

Post by bsder »

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…

> LOC is often a rough approximation for complexity.

I would argue that the word you are looking for is "containment".

Is there any real difference between calling a function and creating a "const varname = { -> insert lots of computation If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. It also ossifies the interface if you have the function as you have to rearrange the function signature to pass in/out new things. Premature optimization ... mumble ... mumble.

Even Carmack mentioned this almost 20 years ago: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Given that we've shrugged off "object-itis" which really demands small functions and given modern IDEs and languages, that kind of inline-style seems a lot more useful than it used to be.

Re: LoC is a dumb metric for functions

#24

Post by imiric »

What an arrogant, wordy, and partly wrong take on this matter.

No, LoC is not a dumb metric. In the same way that cognitive complexity, code coverage, and similar metrics aren't. CC is definitely not "superior" to LoC, it's just different.

These are all signals that point to a piece of code that might need further attention. It is then up to the developer to decide whether to do something about it, or not.

You know what's dumb? Being dogmatic, one way or the other. There are very few hard rules in software development—they're mostly tradeoffs. So whenever I hear someone claiming that X is always bad or always good, I try to poke holes in their argument, or just steer clear from their opinion.

Re: LoC is a dumb metric for functions

#25

Post by RHSeeger »

bsder wrote: post #23
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…

> LOC is often a rough approximation for complexity. I would argue that the word you are looking for is "containment". Is there any real difference between calling a function and creating a "const varname = { -> insert lots of computation If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom. It also ossifies th…

> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom.

I feel exactly the opposite. By moving "self contained" code out of a method, and replacing it with a call, you make it easier to see what the calling location is doing. Ie, you can have a method that says very clearly and concisely what it does... vs making the reader scan through dozens or hundreds of lines of code to understand it all.

Chapter 12 of Kent Beck's book Tidy First? is about exactly this.

Re: LoC is a dumb metric for functions

#26

Post by DanHulton »

It may be a bad metric, if you're being proscriptive, but it's a great heuristic. If I see a 500-line function where I'm not expecting one, I'm going to pay a lot more attention to it in the PR to try to figure out just why it isn't shorter.

Re: LoC is a dumb metric for functions

#27

Post by mirekrusin »

Worth noting that "cognitive complexity" may mean SonarQube metric – a metric that is not widely recognized by industry, created by SonarQube employee as (imho failed) attempt to address "issues" with "cyclomatic complexity" (principled, intdustry recognised metric). It'll count things like nullish coalescing and optional chaning as +1 on your complexity which makes it unusable with jsx or ts code.

With low thresholds ("clean code" like low) both LoC and "cognitive complexity" (as in SQ) are bad measures that lit up in red large percentage of otherwise correct code in complex projects. The way people usually "solve" them is through naive copy pasting which doesn't reduce any cognitive load - it just scatters complexity around making it harder to reason about and modify in the future.

Re: LoC is a dumb metric for functions

#28

Post by imoverclocked »

zdragnar wrote: post #18
imoverclocked wrote: post #9

Earlier quoted context omitted.

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.

> Higher cyclomatic complexity requires more lines

Often true; That's why cognitive complexity wins over cyclomatic complexity.

eg: Embedded logic doesn't add linearly.

fn() { // 1

  if(...) { // +1
    if(...) { // +2
      if(...) { // +3
         ...
      }
    }
  }
} // cognitive complexity of 7 vs cyclomatic complexity of 4

It's been a while since I've implemented anything around this and was remembering cognitive complexity while writing cyclomatic complexity in the previous response. They both have their place but limiting cognitive complexity is vastly more helpful, IMHO. eg: The above code might be better written as guard-clauses to reduce cognitive complexity to 4.

Re: LoC is a dumb metric for functions

#29

Post by adrianN »

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…

I can read small things much better on a high res monitor.

Re: LoC is a dumb metric for functions

#30

Post by Kimitri »

It's not the LoC I care about, it's the logical separation of concerns and testability. Large functions usually do many things which makes them really hard to test. Also, just mashing all the things in a single function is indicative of the author not having a clear picture of what problem he or she is dealing with.

I have been programming for 30 years and, while I don't consider myself a great programmer, I don't like large functions. In my experience they usually fail at clearly expressing intent and therefore make the code a lot harder to reason about. There are, of course, exceptions to this.

Post reply on HN