@comforth3898

That f**king bg music 😖😖😖

@prism223

Functions should provide a useful abstraction.  The length is a secondary concern.  Some good functions are small, some large.

@furkanunsal5814

I like to make every line a function of its own and name them line1() line2()

@fernan.valdes

Reviewing a PR from this guy must be one of the experiences of all time

@BobrLovr

"Depends" should be the only answer.

@OfficialViper

I've been developing for more than 10 years and this is bs. Being too extreme with anything is not good.

@samarnagar9699

Why is the music like that lol

@daven9536

I found that a better heuristic is levels of indentation as opposed to function length. Sequential code in the worst case just adds to the state you have to keep in your head ... branches multiply it.

@JosifovGjorgi

How small should a function be? 

For Uncle Bob that depends on his book publisher, the page margins and other writing books software he uses


For other that write real software - small functions is pain to navigate and maintain even using IDE

The real advice is learn to properly encapsulate code and the functions will be long enough to be easy to understand without too much navigating inside the IDE

@nicolasjoulin3004

the "extract until you can"t extract" is not a good rule, any rule regarding function length is a bad rule.
The real thing to do when you want to know if a function is too long is just "can I explain clearly and sincinctly in english and using simple terms what the function does ?" yes ? function is okay, no ? maybe break it down.
As a matter of fact Bob Martin himself does not follow his rule. his public github profile is public. You can see the code he writes. You can find functions spanning 20+ lines (look at his more-speech project or at his fitnesse project). I am not saying Bob Martin writes bad code, far from it actually. I am just saying he does not apply his own rule and I think there is a very practical reason for it.

@harshitgupta6856

this is how you end up with things like leftpad

@patrickoberholzer4278

Wait until this man discovers Haskell.

@pteranodon6850

As someone who had to work with code that was following this particular rule: don't ... just don't. This is awful advice. And I bet that anyone who has stepped through a sequence of 20 function-calling-function-calling...(you get the idea) can relate.

@AndersBaumann

Better rule: Keep a consistent level of abstraction within the method. This will naturally gives short and easy to read methods.

@NEO97online

Arguing that "classes are hiding inside functions" is masterful level of brainwashing. This is horrible advice, seeking the maximum amount of abstraction possible. We should seek to do the opposite, find the combinatorial explosion of classes and methods and simplify them into the minimal set of abstractions required to do the job.

@miikavihersaari3104

And this is ideological software engineering, working to meet the constraints of an arbitrary idea of how code should be. But software engineering is about producing value, which is a very practical thing.

@jondoty

3:32 "you find the TRUE object oriented structure of the system you're trying to design"
This implies there is only one possible object oriented structure. In reality, there are infinitely many object oriented structures to choose from. What are the odds you chose the best without considering any alternatives or even the fact that it might become object oriented?

@gubx42

A function used to be too big if it didn't fit in a punch card. I still follow this principle but with modern hardware, a function is too big if doesn't fit in a USB stick.

@kerojey4442

Why stop here? Just create new class for each line of code, that will be even more maintainable or whatever buzzwords he uses.....

@jcen_

func main():
	printHelloWorld();

func printHelloWorld():
	print(helloWorld());

func helloWorld():
	return hello() + " " + world() + "!";

func hello():
	return "Hello";

func world():
	return "World";