The winning feature of LoC as a metric is that it can be "eye-balled" easily without tools. Cyclomatic complexity is a more interesting metric; however, it's not the easy, quick, and rather dirty spitball that Lines of Code is.
LoC is a dumb metric for functions
51–60 of 66 posts
Re: LoC is a dumb metric for functions
#52Citation needed. That LoC is the thing that causes bugs may be a dumb idea, but the best available evidence is that it's true.
Suggesting that it's amateur to split up a function that is "too long than X" is spot on, and missing the point at the same time. Amateur coders will also have to read and try to leverage the code. That's why it has utility.
Re: LoC is a dumb metric for functions
#53LOC is an important metric for cost. There's a certain budget of what a person or team can understand/manage.
Re: LoC is a dumb metric for functions
#54Earlier 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…
Back in the day we were rocking 640x480 on a CRT. 800x600 was what the rich kids had.
Re: LoC is a dumb metric for functions
#55LOC 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 worked closely with an engieer that would write these massive long functions; but they read clear and linear. They were really easy to follow and understand.
He'd of course develop functions and macros to avoid repeating themselves.
It just worked for his style and problem solving approach. He knew when to stretch a function. So, I'm convinced long functions can be done elegantly, it's probably uncommon.
Re: LoC is a dumb metric for functions
#56LOC 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…
An example I'm dealing with right now...
At my job, we're not a SaaS. Our software is distributed as cloud images that customers run in their own environments. I need to run regular vulnerability scans on built images.
So, I need to do several things:
- Stand up EC2 instances with our image
- Run our software setup
- Start the scans
- Wait for the scans to complete
- Destroy all the instances
- Download the scan reports
- Upload the reports to S3
- Create Jira tickets based on findings
Now, I COULD easily write it all as one big function. But I tend to prefer to have one "main" function that calls each step as its own function. When looking at the main function, I can much more easily tell what the program is going to do and in what order.
In other words, I much prefer style A from Carmack's post.
Re: LoC is a dumb metric for functions
#57LOC 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…
Do you write comments in your code? If you ever have a long function that like
....
// Here's where we apply coupon codes
...
Inevitably there will come a new special case where, for example, where Gold Members will get to use double coupon codes on Thursday. You'll start by looking in `checkout()` where you'll see either 1000 lines of other special cases, or maybe 30 lines with function calls like `foo = applyCouponCode(shoppingCart, couponCode)`.
For me, it's easier to see where to start with the latter.
Re: LoC is a dumb metric for functions
#58My feelings on LoC really depend on what you want to measure. LoC tends to correlate with # bugs. A 100-line function is probably going to have more bugs than a 20-line function that does the same thing.
I don’t think functions inherently need to be small though. 5 20-line functions are just as buggy as that 1 100-line function. Bugs scale with LoC, not how well you’ve broken functions apart.
The lesson is really just to avoid overcomplicating things. Use less LoC if you can. You should also avoid overly-shortening or cleverness but it tends to be the lesser evil.
Re: LoC is a dumb metric for functions
#59My feelings on LoC really depend on what you want to measure. LoC tends to correlate with # bugs. A 100-line function is probably going to have more bugs than a 20-line function that does the same thing. I don’t think functions inherently need to be small though. 5 20-line functions are just as buggy as that 1 100-line function. Bugs scale with LoC, not how well you’ve broken functions apart. The lesson is really jus…
I’d hazard that the 5 20 line functions are sometimes slightly less buggy, since the function signatures act as essentially an enforced comment on how the implementation is done and perhaps which state is accessed/modified. Versus mutable variables and if-statements in the larger function, that is.
Re: LoC is a dumb metric for functions
#60My feelings on LoC really depend on what you want to measure. LoC tends to correlate with # bugs. A 100-line function is probably going to have more bugs than a 20-line function that does the same thing. I don’t think functions inherently need to be small though. 5 20-line functions are just as buggy as that 1 100-line function. Bugs scale with LoC, not how well you’ve broken functions apart. The lesson is really jus…
I’d hazard that the 5 20 line functions are sometimes slightly less buggy, since the function signatures act as essentially an enforced comment on how the implementation is done and perhaps which state is accessed/modified. Versus mutable variables and if-statements in the larger function, that is.
I’d say more testable. I haven’t seen any metrics on amount of bugs vs composability of functions though. There are metrics on amount of bugs vs LoC.
I have a personal preference towards the “more functions” approach too but I want to separate out my emotional feeling about what’s better vs what’s actually supported with data.