Loc Is a Dumb Metric for Functions

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.

They were one-off projects where he was the sole dev, not part of a larger project. While not mission critical, the 1k line Perl script was helpful at the time. When we ran into a specific issue it allowed for recovery in minutes vs hours. We eventually added safeguards which prevented the issue from happening in the first place.

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 to do then maybe it's better to approach the problem differently.

  if(...) { // +1
    if(...) { // +2
      if(...) { // +3
         ...
      }
    }
  }

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.

That's a special case

John Carmack wrote about inlining code: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

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

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

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.

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.

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

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

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.

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.

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

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

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.