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

41–50 of 66 posts

Re: LoC is a dumb metric for functions

#41

Post by stuaxo »

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…

Exactly, at that level someone is not thinking about how someone else will read and understand the code.

Re: LoC is a dumb metric for functions

#42

Post by frlinook »

xorcist wrote: post #38
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…

After having this discussion in so many professional settings, I'm starting to think that this is just something that divides people. Maybe our brains are wired differently. What's important for me is that the call graph is simple. Second most important is that data structures are easy, or at least fits the problem. The amount of lines in a function is a distant third. It could have been me behind one of those thousa…

[dead]

Re: LoC is a dumb metric for functions

#43

Post by ruszki »

manwe150 wrote: post #4
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…

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.

I don’t understand either. The complexity will be there no matter whether you split up large functions to smaller ones or not. If you need to understand the given function, you need to read and parse the same amount of code. If you blindly trust naming of functions, you will have a bad time. You need to write smaller functions for other reasons, not because of complexity:

- Testing

- Reusability

- Configurability

- Garbage collector/memory management

- etc

I never understood these kind of restrictions in code analysis tools. These kind of restrictions don’t help overall complexity at all, and sometimes they even make things more complex at the end.

Re: LoC is a dumb metric for functions

#44

Post by endymion-light »

xorcist wrote: post #38
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…

After having this discussion in so many professional settings, I'm starting to think that this is just something that divides people. Maybe our brains are wired differently. What's important for me is that the call graph is simple. Second most important is that data structures are easy, or at least fits the problem. The amount of lines in a function is a distant third. It could have been me behind one of those thousa…

I guess I don't really see a reason to have a 1000 line of code function that's not broken down.

Although I personally despise the massive call graphs, my rule of thumb tends to be if I spend over 10 minutes trying to hold all the logic in my head, something is wrong.

Especially with imperative business logic - surely it makes so much more sense to break it down into functions. If you're on call at 2am trying to solve a function with imeprative business logic that someone else has written and has over 1000 lines, you're going to hate yourself, and your coworker.

Re: LoC is a dumb metric for functions

#45

Post by westcoast49 »

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…

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

And today an LLM could probably have refactored it fairly well, automatically.

Re: LoC is a dumb metric for functions

#46

Post by saghm »

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…

I find out useful to split things up sometimes to reduce the number of things in scope at a given time. I've found that this both makes it easier for me to reason about, and anecdotally over the years it seems to correlate with my coworkers finding it easier to review as well, although I suppose it's possible that there's a bit of selection bias in terms of teams being more likely to hire people (and individuals to join teams) with similar mindsets.

Re: LoC is a dumb metric for functions

#47

Post by shakadak »

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 do the computation in my head each time I read it. If it is a function I can cache its behavior more easily compared to a well defined block of code. Even if it's never used anywhere else, it's read multiple time, by multiple people. Obviously, it has to make sense from a domain logic perspective, and not be done for the sake of reducing lines of code, but I have yet to see a function/module/file that is justified in being gigantic when approaching it with domain logic reasoning instead of code execution reasoning.

Re: LoC is a dumb metric for functions

#48

Post by RHSeeger »

bsder wrote: post #32
RHSeeger wrote: post #25

Earlier quoted context omitted.

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

Do not cite Kent Beck as a software authority. Consider this your semi-regular reminder that Kent Beck is part of the posse (along with Ron Jeffries and Martin Fowler) responsible for the software disaster that was the "Chrysler Comprehensive Compensation System". They were also proponents of Smalltalk--which leads to object-itis and the concomitant tiny functions. As for your "function documentation", the primary di…

> Do not cite Kent Beck as a software authority.

I didn't. Rather, I stated my opinion on the subject and then noted that there is a book that discusses the same (so clearly I'm not the only one that thinks this).

> As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments.

No, it's not. It's that the code being moved to a function allows the original location to be cleaner and more obvious.

Re: LoC is a dumb metric for functions

#49

Post by westcoast49 »

xorcist wrote: post #38
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…

After having this discussion in so many professional settings, I'm starting to think that this is just something that divides people. Maybe our brains are wired differently. What's important for me is that the call graph is simple. Second most important is that data structures are easy, or at least fits the problem. The amount of lines in a function is a distant third. It could have been me behind one of those thousa…

I think you're right. I'm on the opposite side of it, but I have a colleague who routinely writes functions that are hundreds of lines long, with 30-40 local variables inside each function. I've come to realize that he does so because his brain allows him to do it. He has a brain that is more detail-oriented than my brain. Where I naturally see a problem as a "tree" of sub-problems with their own details, he naturally sees one large problem with 100 details. He naturally writes code to accommodate his own cognitive style, while I write code to accommodate my own cognitive style.

Moreover, I've come to realize that my colleague is not adverse to using abstractions if they are well established, and if they already exist. But he is (much) less inclined to invent or write new abstractions than I am. As you have concluded, I have also concluded that this is actually a matter of cognitive style, more than it's a symptom of "slop" or "cargo-culting of best practices".

Re: LoC is a dumb metric for functions

#50

Post by delichon »

westcoast49 wrote: post #49
xorcist wrote: post #38

Earlier quoted context omitted.

After having this discussion in so many professional settings, I'm starting to think that this is just something that divides people. Maybe our brains are wired differently. What's important for me is that the call graph is simple. Second most important is that data structures are easy, or at least fits the problem. The amount of lines in a function is a distant third. It could have been me behind one of those thousa…

I think you're right. I'm on the opposite side of it, but I have a colleague who routinely writes functions that are hundreds of lines long, with 30-40 local variables inside each function. I've come to realize that he does so because his brain allows him to do it. He has a brain that is more detail-oriented than my brain. Where I naturally see a problem as a "tree" of sub-problems with their own details, he naturall…

I had a colleague who wrote long functions like that. Over time I came to think of him as an inconsiderate asshole. Unfortunately he was me a few years earlier. I gradually learned the value of organizing code in short sweet methods. When that style become old code, I and my other colleagues came to like that crusty old coder better. I also thought it was a matter of cognitive style but for me it turned out to be inexperience.
Post reply on HN