7 ms·

> Martin asserts that an ideal function is two to four lines of code long This is the kind of assertion that's going to need a very compelling, realistic examp

• ugjka 5y ago
  I've seen a lot of Go code where things are chopped or abstracted on purpose just to make it look nice on "paper" but it is actually really hard to follow what the code does
  • blaerk 5y ago
    I thought it was me being new to go that made some code bases hard to figure out
    • deleted 5y ago
      [deleted]
  • capableweb 5y ago
    A tip from someone who programmed professionally in probably 10 different languages by now, this happen in every single language where you can create abstractions, not just in Go. Could be that it's easier/harder in some languages, but crap programmers exists everywhere.
  • 0des 5y ago
    Golang Channels are like this, in my experience. Like little tubular black boxes where data goes in this Wonka-esque tunnel of wonder.
• Swizec 5y ago
  The easiest way to write unreadable code is by splitting your functionality across 20 clean small functions.
  • Fellshard 5y ago
    Only if said functions are illogically split along non-obvious boundaries. Very frequently, though, I find I can break down concepts to two-three statements in a way that makes it very concise. But also not a hard rule, because there are cases when long-and-drawn-out work as well.
    • philosopher1234 5y ago
      Even logical splits impede readability, because they require tracking and navigation during reading. Every new API has a cost.
      • Fellshard 5y ago
        I take this approach for internal divisions within the same file. For external APIs, you're operating under a completely different set of constraints. As I recall, similar advice was in the original Clean Code: context guides which principles you apply.
      • xboxnolifes 5y ago
        I agree. If a function is only ever likely to be used in the one place it was pulled out of, you're probably better off just using a comment instead.
      • dragonwriter 5y ago
        > Even logical splits impede readability, because they require tracking and navigation during reading. IME, most reading of code has a specific focussed goal for which logical splitting allows not reading lots of irrelevant code you'd have to read if it was a non-abstracted mass.
  • rxhernandez 5y ago
    As someone who regularly inherits functions that are 300 lines long, I'll take 20 clean small functions over that any day.
    • deleted 5y ago
• deleted 5y ago
  [deleted]
• Waterluvian 5y ago
  It seems fundamentally nonsensical. It’s like saying a sentence is ideally 7-14 words long. A sentence should be as long as required to concisely get across one idea. “A function should be as long as required to concisely do one thing” might be a better sentiment. But even then it will have exceptions.
• svnpenn 5y ago
  That advice is absolute garage. That would be like writing a book, but you can only have four sentences per page. Maybe fine for a kids book, but any real author trying this would be laughed at, rightfully.
  • redisman 5y ago
    These little functions seem like writing a book with just [4] 4* footnotes
• treeman79 5y ago
  Multi hundred to thousands of lines of code in a single function that are pure spaghetti code used to be the norm in my early career. I was certainly guilty of it at times. The clean code movement has drastically improved the quality of most projects I’ve seen. I see plenty of garbage but nothing like 20 years ago.
  • rightbyte 5y ago
    Abstract spaghetti is still spaghetti. I prefer having long messy functions for linear reading rather then having to read down call stacks of messy but smaller functions. I get lost way sooner trying to keep the call stack in my head. Easier to debug too. You can place the break-point exactly where you want and don't need to guess which function call order is going to take you somewhere.
    • treeman79 5y ago
      Good point. Super abstract async and messing with global state. Not so fun times
  • lamontcg 5y ago
    There's a spectrum from "pure spaghetti" to what I'd call "clean code enthusiast". The sweet spot is somewhere in the middle. I've definitely refactored code which was done by someone who was clearly a clean code enthusiast where they couldn't generate enough single line methods. I took a lot of those single line methods, that were often used only in one place or where the name of the method was nearly as complicated as the expression that it was replacing and by in-lining them did not produce spaghetti code and which eliminated the cognitive load of that extra method. You have to account for the cost of extracting a method, which is always additional cognitive load and the possible cost of a reader scanning through the source code to look for the definition of the method (even if its still in the same file). When you are cleaning up clear spaghetti code the cost of the cognitive load is generally going to be much less than the benefit of removing the impenetrable spaghetti. But at some limit you no longer have spaghetti code yet you can still continue to pull out methods which are mostly useless abstractions which give the reader more names and more overhead. At that point you're just inventing a complicated domain specific language composed of your methods which are adding pure cognitive overhead to the reader and offering nothing in terms of actual code cleanup. Also not every way of breaking up spaghetti code is equivalent. If you use complicated abstractions in an attempt to avoid code duplication you can wind up with code that is deduplicated and abstracted and not spaghetti but completely impenetrable. I've had success with removing abstractions completely producing simple, clean but duplicated code, and then approaching the de-duplication problem by producing simple instead of complicated abstractions. And when you extract a method you've invented it so you're instantly familiar with what it does and your rationale for naming that way, and it seems perfect and good. When someone else approaches your source code, your subjective rationale for why something was abstracted into a method and what it was named and what it does may not be anywhere near as intuitively obvious. You can generate an affinity for your own abstractions due to the familiarity of inventing them that blinds you to how difficult it is to read your own code for someone with no experience with it. The best code isn't measured by line count of methods or anything like that, but lowest cognitive overhead on the part of the reader. All the objective measures that are offered are really trying to get at that actual subjective measurement. And every single objective rule about writing clean code have edge conditions that you need to violate from time to time to produce actual easy to read code. All rules about clean coding are going to be terrible if they're followed 100% of the time. Some rules are better and should be followed almost all the time, other rules are closer to 80/20 and should be fairly commonly rejected. When you reject a rule you should understand why the rule is there and what it costs when you reject it, and understand what benefit you're getting by rejecting the rule.
• hesdeadjim 5y ago
  I’ll take a 100 line commented function over one that delegates to a dozen other methods that aren’t used anywhere else. The more functions you add to the mix, the less clear the logic becomes and the easier it gets to break things. Abstractions have their place, but the evolution of my 15 year career has led me to use them as a last resort when I find myself needing to copy code more than twice.
  • tuatoru 5y ago
    To me, that's a procedure, not a function. It's a pity that so few of our programming languages distinguish between these two quite different concepts.
    • newaccount74 5y ago
      What is the difference between a function and a procedure to you? I assume it's not just about whether something returns a value or not. The only language I use that differentiates between functions and procedures is PostgreSQL, and to be honest I find the distinction pretty annoying in practice. One can return values, the other can control transactions. So when refactoring code you sometimes need to make a function a procedure or vice versa and it's a pain. (As a consequence, I try to always use functions to make things easier)
      • __vim__ 5y ago
        Fortran distinguishes between the two as well.
  • notreallyserio 5y ago
    I just don't understand how 100 lines comprising 10 or 20 functions in the same file (as in the cited example) is any different than 100 lines of a single function that does the same thing. Is it just that the former has one fewer tab per line? This is the sort of advice that can quickly become a thought terminator because the writer has so much authority.
    • 5y ago
• danielrhodes 5y ago
  …until somebody makes it a lint rule, and you are tasked with making the examples. :-)
• sandofsky 5y ago
  It's interesting because it contradicts the more nuanced opinions of renowned developers like John Carmack. http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Setting aside the lesson, I find Carmack does a wonderful job articulating his argument, whereas the Uncle Bob's put a lot of weight on an appeal to authority.
• SonicScrub 5y ago
  It's worth noting that the book opens by explaining that none of the rules within it's pages should be treated as iron-clad law. Rather they should be treated as guidelines. They should be followed more often than not, but a skilled designer/developer should know when it's appropriate to break them. Keeping functions short is usually good advice, as it helps prevent developers from breaking more important rules such as "one function should do one and only one thing". When writing a function that's becoming too long, memory of this advice should raise a flag in a developer's mind to reconsider restructuring their code. Reconsider. Not act as a robot and restructure to hit some arbitrarily limit. The book is very clear on this. It's been a while since I read Clean Code, but I seem to recall the author giving numerous examples of bad code where it was obvious the developer attempted to condense their code into as few lines as possible at the expense of clarity. This immediately proceeded the advice to keep functions short. The author does this as a warning to not follow this advice blindly. Commenters on this thread are cherry-picking advice from the book and ridiculing it by presenting edge cases where the advice would be bad. To which I imagine the author facepalming and saying "yes, that was the entire point".