3 ms·

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you canno

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to fit it all in your monitor, 1080p being probably the most common resolution that leaves you with roughly 50 to 60 lines of code. If you have to scroll, you might want to consider helper functions to simplify and shorten logic. Functions always being under 10 lines just means you've got functions everywhere, which can be mentally exhausting to follow logic, if you aim for like 40 lines tops you can write better "stories" with your code that are easier to follow and more expressive.

wren6991 3mo ago
I'm fine with a 1k-line function if you just have that many things to do in a row without taking a breath. Breaking it up into smaller functions feels neater when you write it, but when I read it I'm essentially just macro-expanding it in my brain into the original 1k linear version, and that has some cognitive overhead (especially when they end up misordered in the file, or split across different files). I also have to think about whether there are any other areas of the code that might be calling your helpers, and whether they might break if I change the helper. Seeing everything inlined makes it absolutely clear from local reading that modifying the code only affects the local functionality. I'm not saying go insane and copy/paste the same thing multiple times, just that 1k-line functions are sometimes the least of all evils. I liked what John Carmack had to say on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Another point from that post that I try to take to heart: if it can be a pure function, it should be a pure function (even in C). Bob Martin's style is the opposite.
- nomel 3mo ago
  I've heard this called "lasagna code". I've definitely drifted towards longer code, if nothing in that function is used elsewhere. Some tasks really are just lists of things to do (especially in something like image processing), and I think that sometimes it doesn't make sense to put lists of lists in your list of things to do.
  - xnzakg 3mo ago
    But in many cases, you could split it up into smaller, `inline` functions.
    - nomel 3mo ago
      Yes, you can redirect the reader eyes elsewhere as many times as you like. That's the beauty of lasagna. There's a happy medium though. I've seen some people say "functions shouldn't be over 10 lines", which makes code, like I'm describing, near impossible to comprehend, requiring nonsensical divisions of work.
mattmanser 3mo ago
50-60 lines? You must have tiny text size, on mine, with VS Code, I can see 40 lines. As you get past 30 and your eyesight starts changing, you need to up it. By 45 you need it quite a bit bigger than you used to have it. In the mid-2000s there used to be a lot of articles reminding the mainly young developers that 11-12px font size was unreadable to anyone past 40. On top of that, the default place for a console in VS Code is at the bottom, now I'm down to 25-30 lines if I have that open. And then there's heavier IDEs like IntelliJ, Visual studio, etc. They might have two or three tab lines at the top, a row used for class navigation (that I've just realized I've never, ever used), an extra row or two of quick action bars, a row of extra tabs at the bottom for navigating between consoles/call stacks/locals/error lists, 2 info bar rows at the bottom, and sometimes two or even three scroll bars stacked on top of each other. All of a sudden you're down from 30 lines visible to 17, which is my actual visible lines of code when I have debugging running.
- exe34 3mo ago
  I always assumed it was wisdom that made functions smaller and the font bigger, but you may be right- it's ageing!
  - cestith 3mo ago
    We hope to wisen as we age, but there’s no guarantee.
Gibbon1 3mo ago
I keep coming back to the idea he's advocating using long function names as a substitute for comments. Instead of // do the thing followed by 5 lines of code to do the thing. You're supposed to put those five lines in a function named DoTheThing(). That doesn't seem better to me.
- chocrates 3mo ago
  I like function names like that. If your function name is obnoxiously long then you might be doing too much in your function. I'm a bad programmer though and nothing I do is particularly important enough to optimize.

wren6991 3mo ago

I'm fine with a 1k-line function if you just have that many things to do in a row without taking a breath. Breaking it up into smaller functions feels neater when you write it, but when I read it I'm essentially just macro-expanding it in my brain into the original 1k linear version, and that has some cognitive overhead (especially when they end up misordered in the file, or split across different files). I also have to think about whether there are any other areas of the code that might be calling your helpers, and whether they might break if I change the helper. Seeing everything inlined makes it absolutely clear from local reading that modifying the code only affects the local functionality. I'm not saying go insane and copy/paste the same thing multiple times, just that 1k-line functions are sometimes the least of all evils. I liked what John Carmack had to say on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Another point from that post that I try to take to heart: if it can be a pure function, it should be a pure function (even in C). Bob Martin's style is the opposite.

nomel 3mo ago
I've heard this called "lasagna code". I've definitely drifted towards longer code, if nothing in that function is used elsewhere. Some tasks really are just lists of things to do (especially in something like image processing), and I think that sometimes it doesn't make sense to put lists of lists in your list of things to do.
- xnzakg 3mo ago
  But in many cases, you could split it up into smaller, `inline` functions.
  - nomel 3mo ago
    Yes, you can redirect the reader eyes elsewhere as many times as you like. That's the beauty of lasagna. There's a happy medium though. I've seen some people say "functions shouldn't be over 10 lines", which makes code, like I'm describing, near impossible to comprehend, requiring nonsensical divisions of work.

mattmanser 3mo ago

50-60 lines? You must have tiny text size, on mine, with VS Code, I can see 40 lines. As you get past 30 and your eyesight starts changing, you need to up it. By 45 you need it quite a bit bigger than you used to have it. In the mid-2000s there used to be a lot of articles reminding the mainly young developers that 11-12px font size was unreadable to anyone past 40. On top of that, the default place for a console in VS Code is at the bottom, now I'm down to 25-30 lines if I have that open. And then there's heavier IDEs like IntelliJ, Visual studio, etc. They might have two or three tab lines at the top, a row used for class navigation (that I've just realized I've never, ever used), an extra row or two of quick action bars, a row of extra tabs at the bottom for navigating between consoles/call stacks/locals/error lists, 2 info bar rows at the bottom, and sometimes two or even three scroll bars stacked on top of each other. All of a sudden you're down from 30 lines visible to 17, which is my actual visible lines of code when I have debugging running.

exe34 3mo ago
I always assumed it was wisdom that made functions smaller and the font bigger, but you may be right- it's ageing!
- cestith 3mo ago
  We hope to wisen as we age, but there’s no guarantee.

Gibbon1 3mo ago

I keep coming back to the idea he's advocating using long function names as a substitute for comments. Instead of // do the thing followed by 5 lines of code to do the thing. You're supposed to put those five lines in a function named DoTheThing(). That doesn't seem better to me.

chocrates 3mo ago
I like function names like that. If your function name is obnoxiously long then you might be doing too much in your function. I'm a bad programmer though and nothing I do is particularly important enough to optimize.