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

61–66 of 66 posts

Re: LoC is a dumb metric for functions

#61

Post by Kinrany »

stirfish wrote: post #57
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…

Do you write comments in your code? If you ever have a long function that like .... // Here's where we apply coupon codes ... It makes sense to me to break that out into it's own function, preferably one with no side effects that I can write a test for if I need to. I can give it a name related to the business logic. Inevitably there will come a new special case where, for example, where Gold Members will get to use…

Comments are perfectly fine on their own. It's common that a block of code can be given a higher level explanation in a comment, but wouldn't be a good standalone function because it depends on the context too much and so the function has absolutely no chance of ever being used a second time.

Re: LoC is a dumb metric for functions

#62

Post by 1718627440 »

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 a better measure than simple LoCs is to cluster the local variables by use. If you get entirely separate clusters or large clusters that only share a few variables, then you should break them up at the cluster boundaries.

Re: LoC is a dumb metric for functions

#63

Post by 1718627440 »

dgan wrote: post #40
sim7c00 wrote: post #36

Love the article thanks. to me it reads really reasonably. i work in a verbose language (C) and there its too easy to try and optimise things away to 'save typing' to a point it becomes actually more of a burden than an optimization. Some good advices in here on what balance to strike with some clear examples. Always a good reminder :). thanks for the writeup!

I always find it mildly funny/annoying when reading macros which only appear to save the pointer access caracters #define G(l) l->_G What leverage have you achieved there buddy

That can be useful if it is l->foo.bar.baz._G .

Re: LoC is a dumb metric for functions

#64

Post by stirfish »

Kinrany wrote: post #61
stirfish wrote: post #57

Earlier quoted context omitted.

Do you write comments in your code? If you ever have a long function that like .... // Here's where we apply coupon codes ... It makes sense to me to break that out into it's own function, preferably one with no side effects that I can write a test for if I need to. I can give it a name related to the business logic. Inevitably there will come a new special case where, for example, where Gold Members will get to use…

Comments are perfectly fine on their own. It's common that a block of code can be given a higher level explanation in a comment, but wouldn't be a good standalone function because it depends on the context too much and so the function has absolutely no chance of ever being used a second time.

It's okay if a function is only used once. It's worth it to separate it from the context it doesn't need.

Well, twice, including the test. If a block is complex enough to warrant a high level explanation, you might as well capture that intent in a test too.

Edit: in my example, `applyCouponCode` takes in a `shoppingCart` and a `couponCode`, so you know that's all you need to apply a coupon code. You'd change it to something like `applyCouponCode(shoppingCart, couponCode, user.memberStatus)` so you can tell at a glance that `memberStatus` has something to do with how coupons work. You wouldn't want to pass in the whole `user`, because giving the function more than it needs makes it hard to infer what context the function needs and, therefore, what it does.

Re: LoC is a dumb metric for functions

#65

Post by Ferret7446 »

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.

Setting aside the anecdote, this statement is key. If you exclude deliberate efforts to game the LOC metric, LOC is closely correlated to complexity, however else you measure it (branch count, instruction count, variable count, rate of bugs, security vulnerabilities, etc). Unlike any other metrics however, LOC is dead simple to measure. Thus, it's an extremely useful metric, so long as you don't set up an incentive for devs to game it.

Re: LoC is a dumb metric for functions

#66

Post by Kinrany »

stirfish wrote: post #64
Kinrany wrote: post #61

Earlier quoted context omitted.

Comments are perfectly fine on their own. It's common that a block of code can be given a higher level explanation in a comment, but wouldn't be a good standalone function because it depends on the context too much and so the function has absolutely no chance of ever being used a second time.

It's okay if a function is only used once. It's worth it to separate it from the context it doesn't need. Well, twice, including the test. If a block is complex enough to warrant a high level explanation, you might as well capture that intent in a test too. Edit: in my example, `applyCouponCode` takes in a `shoppingCart` and a `couponCode`, so you know that's all you need to apply a coupon code. You'd change it to so…

Tests are code. If the function is easy to test then it's more likely to really be worth having.
Post reply on HN