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.

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.

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)

Fortran distinguishes between the two as well.

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.

The difference is that 1 big functions naturally encodes the ordering and dependencies between things that happen inside - because it's linear and has nested braces.

10 or 20 small functions with no nesting inside still has all the complexity, but none of the structure to help programmer understand it.

Functions can be called in any order, any number of times, and you have to trace the full call-stack in your mind and keep it there to get the same understanding of what happens that you had just by looking at the linear code.

The thing about "functions should be X lines long" is that an appropriate value for X differs substantially from industry to industry, language to language, and domain to domain. My game code (mostly C#/unity stuff) often has longer functions with more commenting, whereas my server code (Go stuff) has virtually none of this. I definitely write 100-line long functions with lots of commenting in C#. I never ever, ever do that in Go. Maybe I would if I was writing a game in Go, but for Go I'm writing servers, and I never ever wind up with code that looks that way in server code.

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.

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

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

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.

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.

Good point. Super abstract async and messing with global state. Not so fun times

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.

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

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.

Golang Channels are like this, in my experience. Like little tubular black boxes where data goes in this Wonka-esque tunnel of wonder.

I thought it was me being new to go that made some code bases hard to figure out

…until somebody makes it a lint rule, and you are tasked with making the examples. :-)

The easiest way to write unreadable code is by splitting your functionality across 20 clean small functions.

It depends. Have you ever read a parser made using combinators? It would be composed of hundreds of small, compact functions called "combinators" that all take the same input (a character or token stream) and produce the same output (a partial parse tree).

They are readable because you can look at any one part and understand what is going on. Referential transparency is important here, as you can be assured each combinator has no strange side effects. Composability is also important, as it gives you an idea as to what each function call does without having to look it up.

If your functions have side effects and 100 different interfaces, then yes, that's a mess and hard to understand. If your functions have predictable interfaces and are referentially transparent, then that's a completely different scenario.

I mean, pretty much every Haskell program ever is split between a number of clean small functions. But for someone who understands Haskell it's hardly unreadable. Quite the opposite.

As someone who regularly inherits functions that are 300 lines long, I'll take 20 clean small functions over that any day.

I am reading this comment section in disbelief. If I were into conspiracy theories, I’d think it’s a spontaneous collaboration to misguide developers and ensure continuous job security for those of us whom desperate businesses would have to hire to clean up and maintain Copilot-generated single-function spaghetti.

Modularizing code into focused units is a big part of how you end up with sustainable software (another important part is understanding the requirements).

One of the easiest ways to make code clearer is to have well-named single-purpose functions that are used in many places.

One of the easiest ways to obfuscate code is to have control flow obscured by hiding it in functions scattered around the codebase.

Getting the former without the latter can actually be difficult, particularly with large teams.

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.

Even logical splits impede readability, because they require tracking and navigation during reading. Every new API has a cost.

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.

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

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.

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.

These little functions seem like writing a book with just [4]

4* footnotes