It's about structures. A long function is unfortunately "flat" at the first glance. Even if there are inherent structures, it usually burns a lot of brain power for a human to abstract structures out of "flat". Being flat is a more acute issue for LLM to understand. I think in the LLM era it's more important than ever to keep things short and structured.
LoC is a dumb metric for functions
31–40 of 66 posts
Re: LoC is a dumb metric for functions
#32Earlier quoted context omitted.
> 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 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 difference between that assignment and a function is solely ossified arguments. And ossified function arguments is something that I would put under "premature abstraction".
At some point you can pull that out into a separate function. But you should have something that causes you to do that rather than it being a default.
Re: LoC is a dumb metric for functions
#33> Locality is the design principle of grouping related things together. It’s a mental shortcut or heuristic that allows the mind to assume a higher degree of independence from the code block being read, easing the mental burden. Spreading code across your codebase diminishes locality.
> Linearity is the idea of having instructions be read one after the other, from top to bottom, just like how code is executed. Having to jump back and forth from function call to function call reduces linearity.
1000 times yes.
Re: LoC is a dumb metric for functions
#34LOC 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…
John Carmack wrote about inlining code: http://number-none.com/blow/john_carmack_on_inlined_code.htm...
Re: LoC is a dumb metric for functions
#35A personal guideline for a lot of stuff is that a function may be too long when people add comments to mark what sections of it do. (ofc not really a hard rule).
I just think it's easier to see "oh this is calling the load_some_stuff function, which I can easily see returns some data from a file." Rather than .
That is to say, descriptive functions names are easier to read than large chunks of code!
smaller functions are also usually easier to test :shrug:
Re: LoC is a dumb metric for functions
#36Love 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!
Re: LoC is a dumb metric for functions
#37Citation needed. That LoC is the thing that causes bugs may be a dumb idea, but the best available evidence is that it's true.
Re: LoC is a dumb metric for functions
#38LOC 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 thousand line functions. Some tings lends itself naturally to this style, such as interpreter-like loops and imperative business logic. There's always that someone that argues that splitting up the code with function calls would somehow make it more "maintainable".
I'm reluctant to do it, because the code is identical, only non-linear which means harder to understand. Combine this with global symbols and it's a recipe for accidental complexity. This is so obvious that I for a long time thought people with the opposite opinion were just cargo-culting some OOP "best practice" mess which has doomed so many projects, but maybe they're just wired differently.
Re: LoC is a dumb metric for functions
#39Earlier quoted context omitted.
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 cyc…
Interestingly, I read once that Hacker News moderators use a similar metric regarding the level of indentation in a thread. It’s a blunt tool to spot flame wars. More replying = more indentation = more heated = less interesting.
Re: LoC is a dumb metric for functions
#40Love 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