prism wrote, _"Functions should provide a useful abstraction."_ No. Functions should be atomic: do one thing and one thing only. Abstraction is the domain of methods and procedures. prism: _"The length of code is a secondary concern."_ The context here is that the length of code is associated, perhaps even correlated, with how many things a function presumes to handle on its own. So, again, *the context* suggests that atomized functions do one thing, and because of this, they're likely to be shorter/smaller. prism: _"Some good functions are small, some large."_ This is too vague a generalization. Perhaps you'll offer an example or two of 'good functions' that are 'large' so that others may consider whether that function really, truly is doing only one thing?
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.
Resonates with me. I'd add that complexity is multiplied to the power of the depth of branching. In the old days, we used to call it "the flying ducks" (anti-pattern).
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.
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
If you need to change a function that does more than one thing, you risk 'breaking' other dependencies on that function. Better is to atomize that function down to its constituent functions and then change the single atom. In a perfect world we could all write ridiculously long procedural code in a single file but... we don't live in a perfect world so, to minimize the risk of breakage, atomizing functions is a 'best practice' for fallible humans.
@@JosifovGjorgi wrote, _"function with 3-4 lines do one thing - they call other functions with 3-4 lines"_ Procedures / methods call other functions. Functions do work and return a value. The procedure or method takes that return value and decides upon state, next action, etc. If all a function does is call another function, then it isn't a function doing the calling.
@@JosifovGjorgiHe didn't say to limit functions to 3-4 lines. That was your criteria. He said functions should do one, and only one, thing well. Why are you resorting to a strawman when you could simply admit that what he said is correct, and your objection has no compelling basis to be preferred? Casting aspersions at him doesn't make your case. Instead, it portrays you as petty.
Extracting leftpad, however small and "trivial" it's implementation might have been, was indeed the right thing to do. Where things went wrong was when it was extracted to a third party package rather than the language's standard library.
The only real problem with Leftpad, other than horendous code (high performing though) that didn't have written tests for it is that it was not on your cache server for those npm packages. Precisely because some idiot could pull it. Leftpad is a good idea (the code is fine, the attempts to fix it were not), NPM is a bad idea.
@@techtutorvideosThey added padStart due to the leftpad incident. But there’s no reason that these abstractions can’t be built by the developer. There is no reason to need a library - even a standard one - for every possible thing under the sun.
1:26, on paper, this is awesome. Problem is that once 1 makes a f(), 1) the rest of the project may call it by accident; 2) More concern for the programmer, more things to have in mind; 3) Compilers work with a limit of f()s to inline, so a performance penalty may be coming. So it's only acceptable if there are at least 2 f()s that should call the new f(), to achieve DRY principle. The best solution is to make that block of code a lambda/inner/private f() of the current f(). If that is not available (unlikely), better is to not touch it. Languages with metaprogramming offer a 3rd solution: to write a macro as the new f(), write the call inside each f()s that should call it, and then undef/delete that macro, for the rest of the code. The concern about who is allowed to change variables (or call "setters" that do that) is a major 1, has a higher priority than either abstraction or performance.
this is all contextual. I think a better rule is as the functions complexity grows the length shrinks. this allows for simple functions like a switch case with maybe 30 something cases to be valid because the simplicity of that function makes it readable and straightfoward
Off wrote, _"I've been developing for more than 10 years and this is bs."_ If you've been developing for a decade and regard this as 'bs', I would question whether you were a competent developer. Off: _"Being too extreme with anything is not good."_ You haven't offered an example from the video that qualifies as 'too extreme' so while your statement may be true, it doesn't relate to anything in the video. "Doesn't relate" = irrelevant.
@@RichardHarlosi mean, writing a function called "primeCheck" to be used in a function called "isPrime" is kind of needless, don't you think? (this was one of the examples the creator put on screen)
@@shipweck6253 If you've been in tech for any length of time, then you also understand that examples are just that: *examples.* They aren't necessary actual code. They're used to illustrate a point. Now, here's the important part: A poorly selected example doesn't negate an otherwise sensible principle. So, if your objection is to the specific example, then you're missing the context. The context is 'break things down whenever you can **AND** whenever your subject-domain knowledge and development experience lead you to do so'. That's the important part. So, don't look so hard at examples to see whether they're good or bad. Instead, look at the examples as you were invited to: as a concrete (even if not real-world) example of _the principle being emphasized._
@@RichardHarlos I've been doing it professionally for 25 years (40 years total programming if you count childhood learning and silly BASIC stuff) and also think it's BS. I've released seven titles in the gaming world, some with budgets in the tens of millions. Want to call me incompetent too? You've already called me a liar. Why stop there?
@@RichardHarlosunfortunately everyone in this industry will use examples to down play a principle they should use in production code. and if you use production code, they tell you they don't understand It's bad faith at its finest
I thought the point of OOP was programming in the problem domain as in modeling the problem into classes and let to solution reveal itself. What’s the point of fitting these little functions into a class after you’ve already solve the problem?
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.
miik wrote, _"And this is ideological software engineering, working to meet the constraints of an arbitrary idea of how code should be."_ Which 'ideal' are you claiming is 'arbitrary'? Don't just make vacuous generalizations. Identify the problem and offer a solution. miik: _"But software engineering is about producing value, which is a very practical thing."_ Engineering overall is about structural and logistical integrity and sufficiency. I don't know what kind of kool-aid you drank that led you to believe that 'engineering' is about 'providing value' but I'd like to consider the source for myself.
@@RichardHarlos By ideological software engineering I was referring to the video. Bob is well known for the Clean Code methodology, which is why my comment wasn't a "vacuous generalization". Clean Code and the SOLID principles are an arbitrary ideology. They are a statement on how you should structure your code in order for it to be clean, but for which there is no metric. Or perhaps you don't know Robert Martin? You wrote: "Engineering overall is about structural and logistical integrity and sufficiency. I don't know what kind of kool-aid you drank that led you to believe that 'engineering' is about 'providing value' but I'd like to consider the source for myself." No, those are the things you need to do in order to provide value. Whatever you engineer, you do it to serve someone, unless it's a meaningless esoteric project. Bridges are built so that passengers can use it, and software is built so that users can use it. Doesn't matter how beautiful your ideology is, what matters is what you deliver, and what value it provides. If a product is performant and does what the user needs it to do, the user is likely to find it valuable. Clean Code, SOLID, object oriented programming, none of them are about solving a real problem. They are about conforming to an arbitrary ideology that supposedly give you some other benefits that haven't really been measured. Also, insults and attacks aren't an argument. They are an emotional response.
Some would say its good practice. Using this and many other techniques that go along side will make code less prone to errors and easier to change in future. It does produce value. If you're coding by yourself then do what the hell you like. If you work in a team the principles and ideas he promotes work well as long as everyone gets it. In physical engineering, parts of a machine have a single job and any machine that needs to be serviced is designed to be extremely modular in terms of replacing a small part. It's nothing more that that.
@@drcl7429 You wrote: "Some would say its good practice. Using this and many other techniques that go along side will make code less prone to errors and easier to change in future. It does produce value." People say all kinds of things just because they've been taught to think a certain way. But whether it's true or not can be determined by measuring. Clean Code often results in lots of abstraction, poor performance and unnecessary complexity that makes maintaining more difficult and costly. You wrote: "If you're coding by yourself then do what the hell you like. If you work in a team the principles and ideas he promotes work well as long as everyone gets it." Sure, but it works even better if the principles are simpler, actually useful and without unnecessary complexity. Simpler is easier to learn and conform to. Besides, every project has principles and guidelines that are specific to each project, so since programmers are constantly adhering to different principles, there's no actual reason to hold on to something that makes engineering more difficult without giving at least an equal benefit in return. You wrote: "In physical engineering, parts of a machine have a single job and any machine that needs to be serviced is designed to be extremely modular in terms of replacing a small part. It's nothing more that that." So let's apply what Bob said on the video about functions to physical engineering. If a part does more than one thing, split it until it does only one. You'd have to split a hammer into the part that is used to pull nails and into another part that is used to drive nails. Any machine would have many times more moving parts, which is a terrible idea.
@@miikavihersaari3104 wrote, _"Clean Code and the SOLID principles are an arbitrary ideology."_ They're hardly arbitrary. Clearly you disagree so please elaborate why, exactly, you believe them to be arbitrary. miik: _"Clean Code, SOLID, object oriented programming, none of them are about solving a real problem."_ Incorrect. They're about abstracting code into structures that are familiar to, and easily understood by, human coders. miik: _" They are about conforming to an arbitrary ideology that supposedly give you some other benefits that haven't really been measured."_ No matter how many times you call 'human readability' and 'familiar abstractions' *"arbitrary",* there's no substance to support what you're saying. I could repeatedly say that your objections are arbitrary, but unless I support that with specific examples and a compelling rationale, I'm just making noise... as you are here. Just because you don't like something on a personal level doesn't mean that it's arbitrary. So, if you're going to make such a claim, then support it with something more substantial than mere repetition. _"They are a statement on how you should structure your code in order for it to be clean, but for which there is no metric."_ The metric is 'human coder readability'. What metric do you propose for this that you believe to be better than actual human experience and feedback? I'm seriously dumb-founded that you would put such effort into arguing against a well-established standard that makes code more consistently readable, and referring to it as 'arbitrary'. Every coding practice has a rationale upon which it's based. If you believe that clean code, solid, and oo are arbitrary, then show me in their rationale which point or points you consider to have zero value, and why you favor your conclusion over others.
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.
if they are well named and use arguments judiciously you do not need to step in to the functions - you can see immediately what they return or do(by their name). I suspect you have been exposed to badly done attempts. It's very common as it takes a good amount of practice to do this properly.
I have been exposed to reality and naming solves nothing. All it takes is some collegues who are not fluent - even then, natural language does not have the precision that programming would require and mistakes happen independently of good practice or intention. I am adamant here: it is maybe a nice idea or aspiration, but it is certainly horrible advice.
@@pteranodon6850 I don't think you have been exposed to it done properly. It's like most of Agile - people think they are doing it but they aren't even close.
@@drcl7429Thank you for continually devaluing my criticism. I don't think I have either, but I have seen some of the failures this advice has produced. What good is advice that works only under high discpline and conditions that are regularly not given in development? I think I made my point clear enough - Uncle Bob has lots of valuable advice for programmers, this isn't one of those and I advice caution, particularly with the "Make it even smaller" rule. Try it if you feel like it, but don't be surprised if you end up with a beautifully named mess of incomprehensibly complex garbage. I warned you the beauty is in the theory for this one.
If you were going for parody, well done. If you think that your example embodies what the video recommended, you missed the context of the video's advice.
I watched the original version of this movie, so to speak, back in the 80s. It's a discipline that fits into the mindset you need to grok lisp or forth. But even with the limitations of 16-bit machines back then we could see that the performance hit of a function call wasn't as significant as some feared. St. Hoare's proclamation that "premature optimization is the root of all evil" was made to remind programmers of the importance of making your code correct before you work on optimization. (Knuth would go on to second Hoare's admonition.) Small functions make it easier to understand your code and verify its correctness. I wouldn't have thought that a controversial suggestion. But that said, I'm not inclined to pursue the idea with the religious purity that Uncle Bob suggests.
Purity is an ideal to be striven toward. But there almost certainly will be exceptions. The thing to notice here is that 'exception' doesn't imply 'rule'. If you have a perfectly sensible analysis of a matter, but there exists some exceptions to that analysis, you don't criticize analysis per se. Instead, you acknowledge the exception and you **document** that it was written a certain way **because** it was, at the time, deemed an exception.
Apologies in advance for this long "article" I don't fully agree on this take. [ Functions ] Firstly, by definition, a "Function" is re-usable code. If its not re-used, its not a "Function", but a container that abstracts logic. The punchcards create a "Scope" issue, that may break the code because developers used said "Functions" for purposes they are not intended to. So they must be declared within the "Scope" of the main "Function" and encapsulated there. The "Scope" should be brodened as needed, not global by default since that can create issues that is hard to debug and fix since it creates a domino effect. [ Classes ] In addition, describing "Functions" as "Classes" is something no programming language does. Yes, they are "Functions" that return objects, but you should never use them to store and manipulate data with no fixed structure like "Functions" do. The data has no fixed structure by design so there is no class that can describe it since it can have data can have multiple structures attached at the same time. If you do use it for this, as the data takes shape, you will end up with an obscure "Class" that is not maintainable since the "Class Attributes" and "Class Methods" are everywhere. That is not the purpose of a Class. [ Writing Code ] All in all, the way a dev should write code should align with the documentation of the software you maintain/develop or the programming language it is written in. A developer should be able to fallback and rely on the documentation. While having a code style that also doubles as a quality of life is nice, these must be done with consideration for the programming langugage guidelines. The style should alter or deter the perception of the said programming language in any way. [ Conclusion ] In my opinion, tech has advanced a long way and this code style has slowly became obsolete over the time. Punchcards became a relic that I personally never heard of or used. They created dangerous scopes and non-statndard classes that may create maintainability issues. Names alone are not enough to describe the programming language context the code is ran in, only its purpose for existing. This is a opinion of an aspiring dev, so please dont take it as professional advice
He doesn't describe functions as classes. Pay attention. If you write code that has well named elements anyone can read and understand it because it, to paraphrase Grady Booch, reads like prose.
If you only call a function once in your program then it doesn't need to be its own function. It only makes your code more confusing because the logic is difficult to read from start to finish. But any time you copy-paste logic from one place in the program to another that should be a function. Doesn't matter how long any of it is because the logic gets split up either way and you have to look at different code to understand it. At least with one long function you can just keep scrolling down instead of jumping around through a bunch of different files with go to definition.
Does this mean you avoid importing libraries because it would be too many functions that you have to jump around to understand? Or does this mean that you avoid creating useful function libraries?
I somewhat agree with this notion that if a function is used in only one place (and has a super specific use case) then it's just cluttering the global namespace. But I'd still advocate for breaking up big functions into its constituents steps, just make sure to make them all private (or if you dont use OOP the next best thing would be to make lambdas inside the big function).
I think if a function is only used once in the application, it does not need to be extracted. And the function call, especially during a loop can slow down the application.
When I write a function/method/subroutine, it "encapsulates" a single operation. This operation may be one or two lines, or 10 or 20, or whatever it needs. And the more loosely-coupled I make it, the more it often needs to encapsulate; but if more than one routine use the same code (or call similar sub-routines) I will make those a separate subroutine. I've always hated having to jump around code to understand how a higher-level code block accomplishes what it does (or does not)--if you need a for loop that does what it does cleanly, there no need to write a function, and pass in 3 or 8 parameters, to accomplish the same thing with a function call.
I completely agree on the contents. But the sound of that video gave me headache. Sounds like it's shifting always from left to right channel and back.
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.
You may notice from his talk that he does NOT give a rule regarding function length. He talks about how function libraries are created and how classes are created via refactoring code.
Like this is borderline just "make every line in a function its own function" levels of stupid. I understand wanting to make functions shorter, but I think the most important reason to extract any function is when you have a snippet of code you want to reuse elsewhere. If there's no point in separating the lines of code into its own function than you don't do it.
Oh ffs he said "extract until you cant MEANINGFULLY extract another function". It's not that hard of a concept. Functions should do "one thing" (which may have multiple steps), and if you notice that a given block might be reusable or might otherwise benefit from its own function you abstract it. Simple as that, and if the function fits on the screen thats a nice plus.
@@fullaccess2645 If a function has multiple steps isn't extracting each step in its own function "meaningful" ? because if so, you SHOULD do it. I wouldn't necessarily. About the "might be reusable", I would tend not to make assumptions about what might or might not happened. Until there is a clear "abstract to reuse" opportunity I would rather keep things as cohesive as possible instead of pre-baking abstractions and complexity into the codebase. function that fits on the screen are nice. On that point, I think extracting for clarity is a good idea occasionally.
Would the extra function calls not cause delays in runtime? I can see this being an issue if latency is important, such as for many engineering and financial applications
Yes, this may be an issue in some applications, in which case a balance between performance and readability will have to be established. Like most (if not all) software development advice this too is not without exceptions, nor cases for which the approach does more harm than good. But unless you know in advance what types of optimizations the application will need, the best approach is to start with a greater bias towards readability and code quality, and to introduce optimizations through benchmarking.
Maintaining the code later on (adding new features and fixing bugs) is very very costly later on, so readable and documented code should be the highest priority. Then you can do some performance testing and figure out where exactly you need to optimize for speed and adjust the code (and document the reason for your changes as well).
3 characters only, everybody who has watched coding tutorials knows, that there are only two names "foo" and "bar", for variables of any type use "myVar" Why do we need all this more or less useless rules ? Should coders permanently be aware not to violate arbitrary rules and waste lots of time in the process? Name your function how ever you like and as long as you like, if you you are not bothered by your own code after a month it's ok. If you have co-workers, they will tell you if you need to change it, then you can discuss that important naming issue over a coffee or two. Search/replace of a name isn't that much of a challenge. But don't waste time with such things, do your actual job: that is writing code which does something useful.
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.
Yeah, by making a function into a class - You've increased the technical complexity - Added more layers of abstraction - Made the code split up and harder to read about - Made bugs more likely to happen
You clearly have not dealt with the opposite of this. The idea of small functions is _FAR_ better than the opposite. I have seen methods that are thousands (plural!) of lines long! Classes that are _tens_ of thousands of lines long. Classes that are so big that dependency injection in the constructor doesn't help, that private variable might as well be global variables. Virtually no excapsulation. Duplicate code everywhere. Insane levels of complexity because, why not add a few dozen more lines to this function? Or, you can have 100 functions that are 20 lines long. Clean, concise functions that don't invite extra code added to them, so developers look elsewhere to add their new functionality. Yeah, I'll take that every day of the week and twice on Sunday.
And after all that... You end up with a piece of software that does exactly the same thing the big ugly function did. Clean and tidy code is important, and if you use an OO language then having a clear structure is good, but this is just moving papers around on a desk. Having a clean desk is necessary to do work at that desk, but cleaning desks is not working at the desk.
Robert has got to stop making these five brain-cell statements about function length. John Carmack kinda went into the reasons why small functions are bad. He said that often longer functions are better because they're much less prone to programmer error. He half-retracted but pretty much only to say that FP features (I assume closures) are even better for solving the same issues. The example code given in Clean Code for function length works almost exclusively through side effects instead of passing values. You're practically writing an object but harder to read. Or maybe make one function with comments outlining each section? "Oh but comments don't run, so they're untested". Neither do function names, you silly, silly man.
Usually smaller functions are less prone to error though since you can easily verify the correctness of a 10 line function. And if you verify the correctness of 10 of those 10 line functions you know the entire thing is correct.
John Carmack exclusively tackles problems with optimisation. These problems only arise after something has been made to work originally. Functional Programming helps you identify the structure of your code and makes it easy to read when writing it. Your comment, on the other hand, is essentially suggesting early optimisation.
@@HazyHerbivore Extremely wrong. Carmack doesn't deal exclusively in optimization, and in the statement mentioned in the comment (you can find it by searching "John Carmack on inlined code"), he recommended the use of longer functions for purely organizational and safety reasons. He also proposes functional programming as a solution to the same problem, but what's being talked about in the video are a series of functions with implicitly shared state, which is effectively the same as writing a single long function but with less explicit dependencies between them
Do you personally know Haskell Curry? It sounds a lot like you are talking about something similar to Currying. Personally I don't like a function to be shorter than a line of code or do less than one thing.
please do not listen to this nuthead. he is all-talk/no-proof kinda dude. if you really want to learn coding learn design patterns from books or CS college.
A function should be easy to grasp in a small amount of time, no matter how long it is. I had a function written by a colleague that was just 12 lines but so riddled by side-effects I had to spend over half an hour figuring out what it did. It was in a Vue project, a so-called "computed getter" that at the same time when getting something was mutating another reactive value. In the effing GETTER. And the naming was not helpful at all. So no complex computations, just very awkward side effects and bad naming. But a short function though that would have fit 5 times on my screen.
I don't remember ever seeing terminals with dimensions 72x24 (?!) The first terminal I used was in 1st-year college, and it was an already old VT-52, with 80x24. The school soon upgraded to VT-100 and Citoh terminals, that could do 132x24.
Every time you extract a function, when you modify it you have to consider everywhere it could be called. If it is only called from that one place, you may have just increased your time to understand the code. Do that enough and you will be very slow.
kf3m wrote, _"Every time you extract a function, when you modify it you have to consider everywhere it could be called."_ Not so. If you follow the heuristic that a function should do *only one thing,* then that function is properly sized and scoped. Atomized functions do one thing, and they don't rely on anything outside of themselves to do that one thing. So, if it does that one thing, and does it correctly, no matter where it may be called from, or how many times, it will do what it's supposed to do without any side effects.
@@RichardHarlos Really? Even a function that does one thing over time might need to do it two different ways as requirements change. I am really curious what types of software you have written where that simplistic heuristic is reasonable to apply all of the time.
@@DaveB-w2i wrote, _"where that simple heuristic is reasonable to apply all of the time."_ I never argued for _"all of the time."_ I've acknowledged special cases, and I've stated that exceptions -- outliers -- don't necessarily negate the heuristic. That said, you appear to have misunderstood my position and perspective. kf3r: _"might need to do it two different ways as requirements change."_ And if/when that becomes an issue, it's simple enough to factor out the 'new way' into its own function, and then decide what flag the software needs in order to decide which version ought to be invoked.
i have to say, don't exact the class from procedural code too early. delay the exaction by 3 repeating occurrences at least, or else you could have designed a wrong leg that is going to be blown off eventually..
A function shoud be as big as it's easy do read. A not so small function can be more readable than a group of realy small ones. It will depend on the problem you are trying do solve. But usually, the smaller the better
I don't think this is good advice. (1) performance. In languages with a stack, each function is a a new stack frame and another level of indirect. Both dammage cashing and slow the processor (2) readability. When reasoning about code, too many functions splits and scatters logic meaning one has to jump around to understand what even simple code does. Often its easier to read and recognise a little code patten then having to lookup were its defined and remembering it by name. (3) premature abstraction. This way of programming lead to writing abstractions around code before youve properly understood the actual problem.
Hi there! While your feedback is welcome, one thing to keep in mind is that software development approaches, languages, etc are just tools. And no tool solves all problems. Yes, this approach may cause a performance penalty, just as it may not. Because of the improvements in both hardware and software, what may have held true a year ago may not hold anymore. A lot of optimizations occur at all levels of the stack so much so that developers now can get away with more than they were once able to. To talk about performance in the abstract may do more harm than good because specifics matter. Generally speaking, the best way to truly tell if an approach/tool will work or not (performance wise) for a given software project is through profiling. 2) Splitting the code into smaller functions will make it hard to read and think about the logic if the functions are not well named, and they don't truly correspond to a subtask of the bigger problem. Meaning that one should not break down code into sub-functions just for the sake of it. One sign you're doing it right is when you start to realize those same sub-functions can be/are of use in other places (because they each represent a meaningful unit of work). But this is not a hard rule. 3) This is a valid point but still, it does not discredit the approach. This is why. The developer is not forced to apply it from the very beginning, neither is the developer forced to stop when all functions are as small as possible. Again, this is a tool that can and should be applied with thought. Nothing prevents the developer from applying it the moment the nature of the problem and the requirements are solid enough. So to say it's not good advice is a broad/extreme statement. What it is, is a tool that may/may not work in some situations. But a tool nonetheless.
@@DevToolsMadeSimpleBut don't you see that there's overhead to splitting a function into smaller functions? It requires thinking and abstraction on what is not even solved yet so you're likely to do a poor job abstracting it anyways. Why not just abstract when it makes sense and not follow a rule that some guy said? If you can't explain why an abstraction works, you're paying the overhead of doing it and likely making it very hard to modify in the future and harder to read. This may not always be the case, but it often is. I envy the people who seem to magically be able to abstract things, maybe it's a skill issue on my part.
@@DevToolsMadeSimple Thank you for your reply. (1) hardware has made incredible advances. We should not squander those hard won gains with self indulgent abstractions, and bad code. It is not hard to make choices that eraise decades of hardware level progress, while not achieving anything that much more impressive then decades old applications. We should focus on building robust, performant and interoperable programs so that our ambition can truly grow as per Gustafson's Law.
@@DevToolsMadeSimple (2) I do believe in writing functions when they are reusable, or for testing pourposes. I feel strongly about this because my tendency is to do this too aggressively, and I have had to rain this back in and so the advice to break down code as much as possible. Also I find it tremendous annoying when I read other people's code, especially who work in an OO style, were I have to waide through several levels of function calls picking up tiny bits of context in each one. So when I head "uncle bob" (self styled) give such wide eaching and exstream advice, it strikes a nerve. I remember how I made a c program slower then the python prototype ( that still hurts ), I remember boxing myself into a corner architecturally as I tried to reuse code that should have been inline and spent so much time trying to make the function that code was put into sufficiently configurable to accomplish its usecases. I remember the pain of realising I could have done in 100 lines what I did in 1000 due to this kind of habit. I got burned coding like this so I don't like his advice
I'm glad this is not so much about inheritance and OOP. More about grouping and structuring by name into "classes". The most descriptive and therefore understandable way to call an API is to explicitely provide all the needed parameters (pure functions). Don't provide them implicitely in the context of the "receiver object", except it is truely internal technical data and therefore some kind of invariant.
Large blocks of code are way more unmaintable. Anyone that has worked in large method or classes will remember when the team didn't want to touch it in fear for effecting the remaining 100 lines of code. What if you get an error stack trace didn't give you an exact line. Good luck but in a small method no big deal. When every thing is broken down and properly named it is easier to read and under stand the code base. It reads more naturally. You can dig as deep as you want or stay at a high level when it us broken up while reading. Also good luck unit testing. You will have to write tons if test because of cyclomatic complexity. I could go on there are also architecture effects(rigid) of doing large methods and classes.
So next time you put 5 things on your to-do list for today, make sure you explode them down to the atomic level where you can no longer break them down into subsequent smaller tasks. Only then, when you have about 348 items on your to-do list, with entries like "walk 2 steps" and "pick up pen", then and only then will you know that you've properly organized your day the way it was always meant to be organized. Perfect logic at its finest...
Error, even when you are partially right. It's not the same organize code than tasks. The program is who, the code is how, the list is what. Then, you are partially right because ( on GTD, or Atomic Habits, or others books about organization), clearly states the bigger is the task, the most difficutl to manage is. But, if you divide your task on steps, then it is easy to be done. And it is easy becasuse ( at mental level), you are focused on one step at the time (small function). Even, on Atomic Habits states that, sometimes, the task can be "pick up pen", in example, if you what to create the habit for writting or drawing. Then, at this point, the "atomic code" helps, because if something fails is easy to know where, and fixing it you fix all the places where this function is called. At your life level, you can be concentrate on fix your organization just and exactly where you are failing or missing
@@drcl7429 No, the GTD method is implemented by people with high responsabilities, even by CEOs. And the principles described by Atomic Habits have been demostrated by sport champions, and are the psicological base on how we create habits. If you haven't, i recommend you to read both books.
Uncle Bob is truly a guru when it comes to teaching how to write incredibly unmaintainable ravioli that gets anyone's blood to boil that has to read into such a codebase.
Appropriately atomized code isn't 'incredibly unmaintainable'. Inappropriately atomized code is more likely to qualify for that criticism. The key, then, isn't to throw out the baby with the bath water. Instead, the key is to learn how to **appropriately** atomize code.
if the functions are badly named or have too many arguments it is terrible. Martin, Beck, Fowler and others are quite forthright in telling you name things right and minimise arguments.
great advice, until we cannot extract anymore... so we should extract i++ to a function i = Increment(i); and there we need to write i = i+1; or we would run into a recursion until the stack freaks out. Bobby needs to get out more of his bubble and write some actual production code, but not in python please. The most importance of code : it should work, do the job required. Customers care how beautiful your code looks ? Sure it shouldn't be an unmaintainable mess, but you can overdo everything. Second most important thing, always ask where you are allowed to put your curly braces. Then maybe let someone beautify it, print it out multiple times for security. Then store in a drawer to rot forever. When AI takes over coding jobs in 20 years, then we will see the worst code ever. Now AI is very able to copy existing code for snake game #637. But it will only get better, so the marketing team says :)
Agreed with everything until he mentioned abstractions. If you habe functions its worth considering the purpose of the function. One purpose is calling other functions. Thing a request handler that calls a validation, sanitisation, then some getData and response function
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?
That’s exactly what I told to those junior and they think I am an idiot. They kept in same skill level but promoted as Senior(not promoted by me. I won’t), that’s the reason why we have tons of bad devs on earth. Wrong people who know nothing on what is a good developer is with the right to promote bad developers
Nah. A function is supposed to do something in a sequence. Sometimes it makes sense to have a big function that does one thing after another, spearated by empty lines and comments. You could cut it to pieces or even make a class out of it, but then reading it would be jumping back and forth between small snippets of code, which is even worse for readability.
A class is a "bunch of variables with a bunch of methods which trates those variables". If you are, joking, suggesting "Just create new class for each line of code", then you didn't understood the class concept at all and that explains why you failed to understand the video.
I think a lot of the critics here are missing the point. Yes, you could use this concept to an overkill level and be left in a hell of one-line, very explicitly named functions. He’s talking about how to take a program that’s been degraded by years of copy-paste coders and turn it into something actually maintainable. Stop trying to prove him wrong with nitpicky details and consider the effect this could have on someone who regularly deals with 200+ line functions who feels trapped and hopeless.
It's not surprising to see terrible code in production if programmers are as dense as this comment section makes it look. So many people missing the point of what he's saying, it's just sad.
I once had to work on a code made this way. It's horrible, nearly impossible to get the whole picture. Don't do it. Split your code into semantic things
Which is why they are put into classes, right? They don't stay global, that was just part of being guided towards the "hiding classes", my understanding was that you don't actually make them global, you just "have to make them global" if you extract the functions but before you realize that it should be a class.
@@fabricehategekimana5350 So how do you build anything meaningful without classes/structs AND without global variables? Like where is your actual application state stored?
@@zeez7777 good point. Classes aren't the only way to create types but OOP make it looks like it, since its concept doesn't provide this level of understanding🤔
there are good places to apply this philosophy but it won't work well if you don't use comments for each one.. trying to keep them under 100 lines is usually a great idea TBH
Wrong! You need less comments. If you use this technique with well thought out names for functions and most variables (iterators get a pass) you will produce self commenting code.
This is great advice. Ive been following this method for a while to pleasing results. It’s been a real positive for readability, test ability, and keeping things changeable as a whole.
Isn't the entire point of classes and functions to be reusable? This method of writing them produces no real reusability since they are all specialized for one hyper-specific task. This is just a fancy way of naming blocks of code. At that point just comment the code. If you wrote it well in the first place, you won't need to explain it (this isn't always true, sometimes inelegant code is inevitable).
So let's say I have a guard clause at the beginning of my function, Should that be abstracted away into a separate function? I'm asking in good faith, I want to know how serious should I be about "doing just one thing". What is ONE thing?
That flies in the face of so much I've been taught. "Make a separate function only when you find an underlying abstraction that can be reused in its general form yadda yadda". I'd like to try it :)
@@crism8868 How does it fly in the face? It's the same. As he said if you can extract a function then you should extract a function because it was doing more than one thing. That extracted function can always be reused. The argument is often WHETHER it will be re-used .
Sure, I can boost your engagement, small TH-camr trying to get bigger on clickbait figures like Uncle Bob. Because I hope you can actually find someone better for this. His whole schtick is making things sound as reputable as possible; giving nonsensical historical reasoning because he looks old instead of actual reasons, and having lots and lots of anecdotes. There are never "rules." His point is that what he says is universal, but if you've ever seen him defend his views, he will also backpedal when asked as if he hasn't repeated it as such million times over. All while having a know-it-all attitude that sounds really good to people who don't know any better and enjoy their "Valley of Mount Stupid" of the Dunning-Kruger curve. He loves insulting the personal reasoning of individuals and their experience to just say "just give them names", as if that makes splicing together single-use functions of 10 lines each to make up what could have been linear code spanning 200 lines of clear and understandable code that is incredibly easy to modify. In his entire career, he hasn't done anything but talk about programming for a living, while not coding a single thing of actual value. He has (to be fair very skillfully) created a career of false credibility and pure fanboyism that everyone inclined to technically excel should avoid. There are so many incredibly skilled programmers actually programming on streams, taking you through their entire process demystifying how they achieve incredible productivity and decision making... And we're STILL clipping this absolute clown. Surely you can find someone else. @DevToolsMadeSimple
@@HaMMeR33661 ["In his entire career, he hasn't done anything but talk about programming for a living, while not coding a single thing of actual value. He has (to be fair very skillfully) created a career of false credibility and pure fanboyism that everyone inclined to technically excel should avoid."] Now this ^ is an extremely bold claim, can you actually prove it? And also, I find it interesting that, even if hypothetically you where right, it would still mean nothing. Many programmers who used his principles and learned with his methods, someone who said something that can work should be recognized as "producing value" in many senses beside purely by writting code. And while many of your criticisms are valid, and I'm not saying that his methodology is the best or anything, you seem very presumptuous by stating things this way and blatantly dismissing Uncle Bob idea's applications in the software industry.
@@diadetediotedio6918 You're paying attention, good. I wasn't clear mainly because I'd like the reader to actually go and look for it themselves. So, go and be curious. I can't really go explain it here -- the mechanisms are very complex. He is a professional at this, you have to understand. His prominence is a calculated effort, and not for his technical skill. But if I may give you a recommendation, Casey Muratori and his sphere of influence has a very different view on the effectiveness on his methods. GingerBill has a 1hour deepdive on some twitter discourse with relevant techniques pointed out. If you disagree, you just don't know what I know. You would be surprised what others have to say.
This is actually bad advice... This video doesn't even give have a reason about why you should do what he says to do.. You should only extract code from a function into a new function when there is a real benefit... I don't care if a function is a couple hundred lines if it does what it is supposed to do & is able to be understood. Writing a fuck ton of functions can actually make code harder to read b/c you are jumping all over the file or "files"... To another point, in a large product some code duplication can be NECESSARY... Its not always the best thing for two teams to re-use some code from some other team... Use judgement, make mistakes, refactor mistakes, ship products & live your life.
Big functions can be good. If you only need to do one thing then there is nothing wrong with a big function. I only split things up if I begin to repeat more than once. Functions can be expensive. The problem with "Uncle Bob" and others is that they disregard the FACT that code runs on hardware and that code is not some abstract thing that only matters to those reading it. Clean-code is slow code and one of the main reasons that programs are so much slower today than they were 20 years ago. Slow code nullifies decades of hardware improvements and erases millions of dollars in innovation.
If you are making a library or it is some critical software whose lifespan is 10s of years, then this is definitely good practice to keep tiddy and refactored to the max. But in consumer and fast b2c software this is not at all recommended. Somwthing that you refactored would be thrown away in a brief moment. Useless to spend time on
12 วันที่ผ่านมา +1
I wish Uncle Bob would only focus on architecture, not this nitty gritty detail. His work on component analysis and stability is so much more important.
Yeah so... what do you do if you work in C and you don't have your precious classes? Just make everything a global struct? Sorry but that entire statement is bull. There is absolutely no reason to split a 6 line functions into two 3 liners just because there is a meaningful way to separate them. Great, so you now have two functions you call exactly once rather than one. Progress has been achieved, can I please have my salary now. Like what kind of ideal is that? Yes, extracting logic from a function and making it smaller is not bad. But only if the function is like 200 lines long, it makes sense to split huge functions like that into smaller groups. The rule of thumb should be that you should just be able to grasp easily what the purpose of a function is. That's why I try and keep my functions smaller than 100 lines. You cannot meaningful infer or reason about a 100+ line function, but it is perfectly possible to keep 70 lines of code in your head and see what a function does at one look. Many programmers seem to forget that source code is a way for the programmer to understand the logic of the program. If you split the program into hundreds of functions you will eventually forget they exist and just have 6 functions do the exact same thing, and while you might have an idea what a 3 line function does, you will not have the slightest idea what that result of the function will be used for 4 functions down the road. So I find that anything below 100 lines does not need to be "meaningfully extracted" into a separate function.
This is what you do in C: you group related functions into different files called "libraries". Each library contains a group of functions, each of those functions should do "one thing". If the one thing they do takes multiple steps, and you see meaning/value in extracting said steps into different functions for the sake of readability/reusability/maintainability then do so. Simple as that. Now some free advice: you might find a function is too big, yet notice that extracting a piece into another function would not be very useful in terms of reusability. In those cases you should extract anyway into a static (aka private) function for the sake of readability. If by doing this, you find that *most* functions fit on the screen and the indentation *almost* never goes past 3 levels youve done it correctly.
But, did anything he said represent an error in his rationale? If not, then it's irrelevant whether he smells his own farts. What are you, some kind of wanna-be comedian?
That f**king bg music 😖😖😖
I cried, I DON'T CRY.
what's the name of that song?
yup it is irritating as fuck
Yep, should be louder :)
Functions should provide a useful abstraction. The length is a secondary concern. Some good functions are small, some large.
Exactly. Its a silly debate.
W and correct take
How dare you
If it's large, then it's not a good function. Break it into smaller ones.
prism wrote, _"Functions should provide a useful abstraction."_
No. Functions should be atomic: do one thing and one thing only. Abstraction is the domain of methods and procedures.
prism: _"The length of code is a secondary concern."_
The context here is that the length of code is associated, perhaps even correlated, with how many things a function presumes to handle on its own. So, again, *the context* suggests that atomized functions do one thing, and because of this, they're likely to be shorter/smaller.
prism: _"Some good functions are small, some large."_
This is too vague a generalization. Perhaps you'll offer an example or two of 'good functions' that are 'large' so that others may consider whether that function really, truly is doing only one thing?
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.
This a good way to think about it.
Resonates with me. I'd add that complexity is multiplied to the power of the depth of branching. In the old days, we used to call it "the flying ducks" (anti-pattern).
You can measure this. It's called cyclomatic complexity.
@@jxkcd Yes static analysis tools. We use Open Cover which measures other types of complexity to produce a score it calls C.R.A.P. 😆
Then just do not indent. ;-)
I like to make every line a function of its own and name them line1() line2()
this is the only correct answer
Pure genius. I always heard I shouldn't use goto. Now I don't have to and still have its functionality. Everybody wins. :)
Something similar was done in the 80s, though they weren't functions. You had to numerate lines.
@@pedroamaralcouto do you mean the basic programming langauge? I always found that extremely absurd haha
that is the best idea I have ever seen to legalize the use of goto
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.
So, if you have a 2TB stick, a function is not too big if it's merely 1.5TB, right?
That seems to be the rule that OS and game companies often follow.
"Depends" should be the only answer.
Why is the music like that lol
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
If you need to change a function that does more than one thing, you risk 'breaking' other dependencies on that function. Better is to atomize that function down to its constituent functions and then change the single atom. In a perfect world we could all write ridiculously long procedural code in a single file but... we don't live in a perfect world so, to minimize the risk of breakage, atomizing functions is a 'best practice' for fallible humans.
@@RichardHarlos function with 3-4 lines do one thing - they call other functions with 3-4 lines
@@JosifovGjorgi wrote, _"function with 3-4 lines do one thing - they call other functions with 3-4 lines"_
Procedures / methods call other functions. Functions do work and return a value. The procedure or method takes that return value and decides upon state, next action, etc.
If all a function does is call another function, then it isn't a function doing the calling.
@@RichardHarlos
"Functions do work and return a value." - how much work can a function do in 3-4 lines ?
@@JosifovGjorgiHe didn't say to limit functions to 3-4 lines. That was your criteria. He said functions should do one, and only one, thing well. Why are you resorting to a strawman when you could simply admit that what he said is correct, and your objection has no compelling basis to be preferred?
Casting aspersions at him doesn't make your case. Instead, it portrays you as petty.
Better rule: Keep a consistent level of abstraction within the method. This will naturally gives short and easy to read methods.
this is how you end up with things like leftpad
Extracting leftpad, however small and "trivial" it's implementation might have been, was indeed the right thing to do. Where things went wrong was when it was extracted to a third party package rather than the language's standard library.
No, it's like is-number that requires is-not-number, is-string, is-array, is-*
The only real problem with Leftpad, other than horendous code (high performing though) that didn't have written tests for it is that it was not on your cache server for those npm packages. Precisely because some idiot could pull it. Leftpad is a good idea (the code is fine, the attempts to fix it were not), NPM is a bad idea.
@@techtutorvideosThey added padStart due to the leftpad incident.
But there’s no reason that these abstractions can’t be built by the developer. There is no reason to need a library - even a standard one - for every possible thing under the sun.
@@zTJq40sl you really need std to have leftpad really ? what next fib? isPrime?
THe music is so obnoxious lol
1:26, on paper, this is awesome. Problem is that once 1 makes a f(), 1) the rest of the project may call it by accident; 2) More concern for the programmer, more things to have in mind; 3) Compilers work with a limit of f()s to inline, so a performance penalty may be coming. So it's only acceptable if there are at least 2 f()s that should call the new f(), to achieve DRY principle.
The best solution is to make that block of code a lambda/inner/private f() of the current f(). If that is not available (unlikely), better is to not touch it. Languages with metaprogramming offer a 3rd solution: to write a macro as the new f(), write the call inside each f()s that should call it, and then undef/delete that macro, for the rest of the code.
The concern about who is allowed to change variables (or call "setters" that do that) is a major 1, has a higher priority than either abstraction or performance.
this is all contextual. I think a better rule is as the functions complexity grows the length shrinks. this allows for simple functions like a switch case with maybe 30 something cases to be valid because the simplicity of that function makes it readable and straightfoward
I've been developing for more than 10 years and this is bs. Being too extreme with anything is not good.
Off wrote, _"I've been developing for more than 10 years and this is bs."_
If you've been developing for a decade and regard this as 'bs', I would question whether you were a competent developer.
Off: _"Being too extreme with anything is not good."_
You haven't offered an example from the video that qualifies as 'too extreme' so while your statement may be true, it doesn't relate to anything in the video. "Doesn't relate" = irrelevant.
@@RichardHarlosi mean, writing a function called "primeCheck" to be used in a function called "isPrime" is kind of needless, don't you think? (this was one of the examples the creator put on screen)
@@shipweck6253 If you've been in tech for any length of time, then you also understand that examples are just that: *examples.*
They aren't necessary actual code. They're used to illustrate a point. Now, here's the important part:
A poorly selected example doesn't negate an otherwise sensible principle. So, if your objection is to the specific example, then you're missing the context. The context is 'break things down whenever you can **AND** whenever your subject-domain knowledge and development experience lead you to do so'. That's the important part.
So, don't look so hard at examples to see whether they're good or bad. Instead, look at the examples as you were invited to: as a concrete (even if not real-world) example of _the principle being emphasized._
@@RichardHarlos I've been doing it professionally for 25 years (40 years total programming if you count childhood learning and silly BASIC stuff) and also think it's BS. I've released seven titles in the gaming world, some with budgets in the tens of millions. Want to call me incompetent too? You've already called me a liar. Why stop there?
@@RichardHarlosunfortunately everyone in this industry will use examples to down play a principle they should use in production code.
and if you use production code, they tell you they don't understand
It's bad faith at its finest
I thought the point of OOP was programming in the problem domain as in modeling the problem into classes and let to solution reveal itself. What’s the point of fitting these little functions into a class after you’ve already solve the problem?
Maintainability. When you write a software it is in your head. Go back to change something half a year later and it looks like a crossword puzzle.
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.
miik wrote, _"And this is ideological software engineering, working to meet the constraints of an arbitrary idea of how code should be."_
Which 'ideal' are you claiming is 'arbitrary'? Don't just make vacuous generalizations. Identify the problem and offer a solution.
miik: _"But software engineering is about producing value, which is a very practical thing."_
Engineering overall is about structural and logistical integrity and sufficiency. I don't know what kind of kool-aid you drank that led you to believe that 'engineering' is about 'providing value' but I'd like to consider the source for myself.
@@RichardHarlos By ideological software engineering I was referring to the video. Bob is well known for the Clean Code methodology, which is why my comment wasn't a "vacuous generalization". Clean Code and the SOLID principles are an arbitrary ideology. They are a statement on how you should structure your code in order for it to be clean, but for which there is no metric. Or perhaps you don't know Robert Martin?
You wrote: "Engineering overall is about structural and logistical integrity and sufficiency. I don't know what kind of kool-aid you drank that led you to believe that 'engineering' is about 'providing value' but I'd like to consider the source for myself."
No, those are the things you need to do in order to provide value. Whatever you engineer, you do it to serve someone, unless it's a meaningless esoteric project. Bridges are built so that passengers can use it, and software is built so that users can use it. Doesn't matter how beautiful your ideology is, what matters is what you deliver, and what value it provides. If a product is performant and does what the user needs it to do, the user is likely to find it valuable.
Clean Code, SOLID, object oriented programming, none of them are about solving a real problem. They are about conforming to an arbitrary ideology that supposedly give you some other benefits that haven't really been measured.
Also, insults and attacks aren't an argument. They are an emotional response.
Some would say its good practice. Using this and many other techniques that go along side will make code less prone to errors and easier to change in future. It does produce value.
If you're coding by yourself then do what the hell you like. If you work in a team the principles and ideas he promotes work well as long as everyone gets it.
In physical engineering, parts of a machine have a single job and any machine that needs to be serviced is designed to be extremely modular in terms of replacing a small part. It's nothing more that that.
@@drcl7429 You wrote: "Some would say its good practice. Using this and many other techniques that go along side will make code less prone to errors and easier to change in future. It does produce value."
People say all kinds of things just because they've been taught to think a certain way. But whether it's true or not can be determined by measuring. Clean Code often results in lots of abstraction, poor performance and unnecessary complexity that makes maintaining more difficult and costly.
You wrote: "If you're coding by yourself then do what the hell you like. If you work in a team the principles and ideas he promotes work well as long as everyone gets it."
Sure, but it works even better if the principles are simpler, actually useful and without unnecessary complexity. Simpler is easier to learn and conform to. Besides, every project has principles and guidelines that are specific to each project, so since programmers are constantly adhering to different principles, there's no actual reason to hold on to something that makes engineering more difficult without giving at least an equal benefit in return.
You wrote: "In physical engineering, parts of a machine have a single job and any machine that needs to be serviced is designed to be extremely modular in terms of replacing a small part. It's nothing more that that."
So let's apply what Bob said on the video about functions to physical engineering. If a part does more than one thing, split it until it does only one. You'd have to split a hammer into the part that is used to pull nails and into another part that is used to drive nails. Any machine would have many times more moving parts, which is a terrible idea.
@@miikavihersaari3104 wrote, _"Clean Code and the SOLID principles are an arbitrary ideology."_
They're hardly arbitrary. Clearly you disagree so please elaborate why, exactly, you believe them to be arbitrary.
miik: _"Clean Code, SOLID, object oriented programming, none of them are about solving a real problem."_
Incorrect. They're about abstracting code into structures that are familiar to, and easily understood by, human coders.
miik: _" They are about conforming to an arbitrary ideology that supposedly give you some other benefits that haven't really been measured."_
No matter how many times you call 'human readability' and 'familiar abstractions' *"arbitrary",* there's no substance to support what you're saying.
I could repeatedly say that your objections are arbitrary, but unless I support that with specific examples and a compelling rationale, I'm just making noise... as you are here.
Just because you don't like something on a personal level doesn't mean that it's arbitrary. So, if you're going to make such a claim, then support it with something more substantial than mere repetition.
_"They are a statement on how you should structure your code in order for it to be clean, but for which there is no metric."_
The metric is 'human coder readability'. What metric do you propose for this that you believe to be better than actual human experience and feedback?
I'm seriously dumb-founded that you would put such effort into arguing against a well-established standard that makes code more consistently readable, and referring to it as 'arbitrary'. Every coding practice has a rationale upon which it's based. If you believe that clean code, solid, and oo are arbitrary, then show me in their rationale which point or points you consider to have zero value, and why you favor your conclusion over others.
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.
if they are well named and use arguments judiciously you do not need to step in to the functions - you can see immediately what they return or do(by their name).
I suspect you have been exposed to badly done attempts. It's very common as it takes a good amount of practice to do this properly.
@@drcl7429 for debugging you still need to steep into these functions
I have been exposed to reality and
naming solves nothing. All it takes is some collegues who are not fluent - even then, natural language does not have the precision that programming would require and mistakes happen independently of good practice or intention.
I am adamant here: it is maybe a nice idea or aspiration, but it is certainly horrible advice.
@@pteranodon6850 I don't think you have been exposed to it done properly. It's like most of Agile - people think they are doing it but they aren't even close.
@@drcl7429Thank you for continually devaluing my criticism. I don't think I have either, but I have seen some of the failures this advice has produced. What good is advice that works only under high discpline and conditions that are regularly not given in development?
I think I made my point clear enough - Uncle Bob has lots of valuable advice for programmers, this isn't one of those and I advice caution, particularly with the "Make it even smaller" rule. Try it if you feel like it, but don't be surprised if you end up with a beautifully named mess of incomprehensibly complex garbage. I warned you the beauty is in the theory for this one.
func main():
printHelloWorld();
func printHelloWorld():
print(helloWorld());
func helloWorld():
return hello() + " " + world() + "!";
func hello():
return "Hello";
func world():
return "World";
Great example. And let's of course not forget to put those in separate classes. 🙄
Exception: not enough functions. You've missed exclamationMark(). Needs work.
If you were going for parody, well done. If you think that your example embodies what the video recommended, you missed the context of the video's advice.
exactly how system libraries look.
@@RichardHarlos Not at all. Bob literally said you should keep breaking functions into more functions as long as it's possible.
I watched the original version of this movie, so to speak, back in the 80s. It's a discipline that fits into the mindset you need to grok lisp or forth. But even with the limitations of 16-bit machines back then we could see that the performance hit of a function call wasn't as significant as some feared.
St. Hoare's proclamation that "premature optimization is the root of all evil" was made to remind programmers of the importance of making your code correct before you work on optimization. (Knuth would go on to second Hoare's admonition.) Small functions make it easier to understand your code and verify its correctness. I wouldn't have thought that a controversial suggestion. But that said, I'm not inclined to pursue the idea with the religious purity that Uncle Bob suggests.
Purity is an ideal to be striven toward. But there almost certainly will be exceptions. The thing to notice here is that 'exception' doesn't imply 'rule'. If you have a perfectly sensible analysis of a matter, but there exists some exceptions to that analysis, you don't criticize analysis per se. Instead, you acknowledge the exception and you **document** that it was written a certain way **because** it was, at the time, deemed an exception.
If you care about performance, you had better use a compiled language which can automatically inline function calls.
i appreciate the visualizers you put in between, nicely done!
Much appreciated!
Apologies in advance for this long "article"
I don't fully agree on this take.
[ Functions ]
Firstly, by definition, a "Function" is re-usable code. If its not re-used, its not a "Function", but a container that abstracts logic.
The punchcards create a "Scope" issue, that may break the code because developers used said "Functions" for purposes they are not intended to.
So they must be declared within the "Scope" of the main "Function" and encapsulated there.
The "Scope" should be brodened as needed, not global by default since that can create issues that is hard to debug and fix since it creates a domino effect.
[ Classes ]
In addition, describing "Functions" as "Classes" is something no programming language does.
Yes, they are "Functions" that return objects, but you should never use them to store and manipulate data with no fixed structure like "Functions" do.
The data has no fixed structure by design so there is no class that can describe it since it can have data can have multiple structures attached at the same time.
If you do use it for this, as the data takes shape, you will end up with an obscure "Class" that is not maintainable since the "Class Attributes" and "Class Methods" are everywhere.
That is not the purpose of a Class.
[ Writing Code ]
All in all, the way a dev should write code should align with the documentation of the software you maintain/develop or the programming language it is written in.
A developer should be able to fallback and rely on the documentation.
While having a code style that also doubles as a quality of life is nice, these must be done with consideration for the programming langugage guidelines.
The style should alter or deter the perception of the said programming language in any way.
[ Conclusion ]
In my opinion, tech has advanced a long way and this code style has slowly became obsolete over the time.
Punchcards became a relic that I personally never heard of or used.
They created dangerous scopes and non-statndard classes that may create maintainability issues.
Names alone are not enough to describe the programming language context the code is ran in, only its purpose for existing.
This is a opinion of an aspiring dev, so please dont take it as professional advice
He doesn't describe functions as classes. Pay attention.
If you write code that has well named elements anyone can read and understand it because it, to paraphrase Grady Booch, reads like prose.
If you only call a function once in your program then it doesn't need to be its own function. It only makes your code more confusing because the logic is difficult to read from start to finish. But any time you copy-paste logic from one place in the program to another that should be a function. Doesn't matter how long any of it is because the logic gets split up either way and you have to look at different code to understand it. At least with one long function you can just keep scrolling down instead of jumping around through a bunch of different files with go to definition.
Does this mean you avoid importing libraries because it would be too many functions that you have to jump around to understand?
Or does this mean that you avoid creating useful function libraries?
I somewhat agree with this notion that if a function is used in only one place (and has a super specific use case) then it's just cluttering the global namespace. But I'd still advocate for breaking up big functions into its constituents steps, just make sure to make them all private (or if you dont use OOP the next best thing would be to make lambdas inside the big function).
I think if a function is only used once in the application, it does not need to be extracted. And the function call, especially during a loop can slow down the application.
But return link of a function is stored on a stack, which is the fastest type of memory we have in a computer system (barring registers).
When I write a function/method/subroutine, it "encapsulates" a single operation. This operation may be one or two lines, or 10 or 20, or whatever it needs. And the more loosely-coupled I make it, the more it often needs to encapsulate; but if more than one routine use the same code (or call similar sub-routines) I will make those a separate subroutine.
I've always hated having to jump around code to understand how a higher-level code block accomplishes what it does (or does not)--if you need a for loop that does what it does cleanly, there no need to write a function, and pass in 3 or 8 parameters, to accomplish the same thing with a function call.
I completely agree on the contents. But the sound of that video gave me headache. Sounds like it's shifting always from left to right channel and back.
He looks like a real madman to me. Name a sea of functions|structs|modules - is a real challenge for me.
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.
You may notice from his talk that he does NOT give a rule regarding function length. He talks about how function libraries are created and how classes are created via refactoring code.
Like this is borderline just "make every line in a function its own function" levels of stupid. I understand wanting to make functions shorter, but I think the most important reason to extract any function is when you have a snippet of code you want to reuse elsewhere. If there's no point in separating the lines of code into its own function than you don't do it.
Oh ffs he said "extract until you cant MEANINGFULLY extract another function". It's not that hard of a concept. Functions should do "one thing" (which may have multiple steps), and if you notice that a given block might be reusable or might otherwise benefit from its own function you abstract it. Simple as that, and if the function fits on the screen thats a nice plus.
@@fullaccess2645 If a function has multiple steps isn't extracting each step in its own function "meaningful" ? because if so, you SHOULD do it. I wouldn't necessarily.
About the "might be reusable", I would tend not to make assumptions about what might or might not happened. Until there is a clear "abstract to reuse" opportunity I would rather keep things as cohesive as possible instead of pre-baking abstractions and complexity into the codebase.
function that fits on the screen are nice. On that point, I think extracting for clarity is a good idea occasionally.
Would the extra function calls not cause delays in runtime? I can see this being an issue if latency is important, such as for many engineering and financial applications
Yes, this may be an issue in some applications, in which case a balance between performance and readability will have to be established. Like most (if not all) software development advice this too is not without exceptions, nor cases for which the approach does more harm than good. But unless you know in advance what types of optimizations the application will need, the best approach is to start with a greater bias towards readability and code quality, and to introduce optimizations through benchmarking.
In systems languages, you can mark your functions inline. In higher level langs, these optimizations aren’t important.
Maintaining the code later on (adding new features and fixing bugs) is very very costly later on, so readable and documented code should be the highest priority. Then you can do some performance testing and figure out where exactly you need to optimize for speed and adjust the code (and document the reason for your changes as well).
@@svdragster you're ignoring the fact that jumping between 100 functions is not more readable than following a program top to bottom.
Yeah it doesn’t help readability but the lack of so many side effects can make it easier to maintain.
A class with N private fields and M private methods is equivalent to a function with N variables and M local functions
How long should a function name be?
Short enough to fit on one line *on your phone*. Got that, MSFT?
betwean 4 and 12 letters
Long enough to be descriptive of what it does. But, if you cant' describe it in 2-3 words, maybe 4 max, then maybe that's telling you something ...
how long should a TDD test function name be?
3 characters only, everybody who has watched coding tutorials knows, that there are only two names
"foo" and "bar", for variables of any type use "myVar"
Why do we need all this more or less useless rules ? Should coders permanently be aware not to violate arbitrary rules and waste lots of time in the process?
Name your function how ever you like and as long as you like, if you you are not bothered by your own code after a month it's ok.
If you have co-workers, they will tell you if you need to change it, then you can discuss that important naming issue over a coffee or two.
Search/replace of a name isn't that much of a challenge.
But don't waste time with such things, do your actual job: that is writing code which does something useful.
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.
Yeah, by making a function into a class
- You've increased the technical complexity
- Added more layers of abstraction
- Made the code split up and harder to read about
- Made bugs more likely to happen
You clearly have not dealt with the opposite of this. The idea of small functions is _FAR_ better than the opposite. I have seen methods that are thousands (plural!) of lines long! Classes that are _tens_ of thousands of lines long. Classes that are so big that dependency injection in the constructor doesn't help, that private variable might as well be global variables. Virtually no excapsulation. Duplicate code everywhere. Insane levels of complexity because, why not add a few dozen more lines to this function?
Or, you can have 100 functions that are 20 lines long. Clean, concise functions that don't invite extra code added to them, so developers look elsewhere to add their new functionality.
Yeah, I'll take that every day of the week and twice on Sunday.
And after all that... You end up with a piece of software that does exactly the same thing the big ugly function did.
Clean and tidy code is important, and if you use an OO language then having a clear structure is good, but this is just moving papers around on a desk. Having a clean desk is necessary to do work at that desk, but cleaning desks is not working at the desk.
Alot of people mis the point of this clip. It is not About length it is About a function should do one thing
It's about length.
I don't think bottle on the table contains water.
The water has been extracted from the bottle, to make the bottle simpler.
Robert has got to stop making these five brain-cell statements about function length. John Carmack kinda went into the reasons why small functions are bad. He said that often longer functions are better because they're much less prone to programmer error. He half-retracted but pretty much only to say that FP features (I assume closures) are even better for solving the same issues. The example code given in Clean Code for function length works almost exclusively through side effects instead of passing values. You're practically writing an object but harder to read. Or maybe make one function with comments outlining each section? "Oh but comments don't run, so they're untested". Neither do function names, you silly, silly man.
Funny how much the video seems like a preacher's sermon
Usually smaller functions are less prone to error though since you can easily verify the correctness of a 10 line function. And if you verify the correctness of 10 of those 10 line functions you know the entire thing is correct.
John Carmack exclusively tackles problems with optimisation. These problems only arise after something has been made to work originally. Functional Programming helps you identify the structure of your code and makes it easy to read when writing it. Your comment, on the other hand, is essentially suggesting early optimisation.
@@HazyHerbivore ...and "premature optimisation is the root of all evil" [Hoare, sometimes attributed to Knuth]... :)
@@HazyHerbivore Extremely wrong. Carmack doesn't deal exclusively in optimization, and in the statement mentioned in the comment (you can find it by searching "John Carmack on inlined code"), he recommended the use of longer functions for purely organizational and safety reasons.
He also proposes functional programming as a solution to the same problem, but what's being talked about in the video are a series of functions with implicitly shared state, which is effectively the same as writing a single long function but with less explicit dependencies between them
Do you personally know Haskell Curry? It sounds a lot like you are talking about something similar to Currying. Personally I don't like a function to be shorter than a line of code or do less than one thing.
Wait until this man discovers Haskell.
His favourite at the moment is Clojure.
you watching this, don't you ever join my team to code in this rage-inducing manner.
He has manic personality traits. The rapid head turning is tell-tale.
Great advice. Thanks!
please do not listen to this nuthead. he is all-talk/no-proof kinda dude. if you really want to learn coding learn design patterns from books or CS college.
A function should be easy to grasp in a small amount of time, no matter how long it is. I had a function written by a colleague that was just 12 lines but so riddled by side-effects I had to spend over half an hour figuring out what it did. It was in a Vue project, a so-called "computed getter" that at the same time when getting something was mutating another reactive value. In the effing GETTER. And the naming was not helpful at all. So no complex computations, just very awkward side effects and bad naming. But a short function though that would have fit 5 times on my screen.
I don't remember ever seeing terminals with dimensions 72x24 (?!)
The first terminal I used was in 1st-year college, and it was an already old VT-52, with 80x24. The school soon upgraded to VT-100 and Citoh terminals, that could do 132x24.
Functions should have a clear input and a clear output and as few side effects as possible. The size doesnt really matter that much.
Every time you extract a function, when you modify it you have to consider everywhere it could be called. If it is only called from that one place, you may have just increased your time to understand the code. Do that enough and you will be very slow.
... or look very busy. Good if you get paid hourly.
kf3m wrote, _"Every time you extract a function, when you modify it you have to consider everywhere it could be called."_
Not so. If you follow the heuristic that a function should do *only one thing,* then that function is properly sized and scoped. Atomized functions do one thing, and they don't rely on anything outside of themselves to do that one thing. So, if it does that one thing, and does it correctly, no matter where it may be called from, or how many times, it will do what it's supposed to do without any side effects.
Which is why you have to practice this from line 1. Much harder to do this with existing code.
@@RichardHarlos Really? Even a function that does one thing over time might need to do it two different ways as requirements change. I am really curious what types of software you have written where that simplistic heuristic is reasonable to apply all of the time.
@@DaveB-w2i wrote, _"where that simple heuristic is reasonable to apply all of the time."_
I never argued for _"all of the time."_ I've acknowledged special cases, and I've stated that exceptions -- outliers -- don't necessarily negate the heuristic. That said, you appear to have misunderstood my position and perspective.
kf3r: _"might need to do it two different ways as requirements change."_
And if/when that becomes an issue, it's simple enough to factor out the 'new way' into its own function, and then decide what flag the software needs in order to decide which version ought to be invoked.
i have to say, don't exact the class from procedural code too early. delay the exaction by 3 repeating occurrences at least, or else you could have designed a wrong leg that is going to be blown off eventually..
Premature abstraction is bad.
that's what she said
R*st fans seething rn
it can be if you have OCD.
Why is the audio so bad?
he sounds like a sped up robot
Extract n Extract n Extract n Extract ... 😄💪 Yeah Baby! Boss Uncle Bob!
A function shoud be as big as it's easy do read. A not so small function can be more readable than a group of realy small ones. It will depend on the problem you are trying do solve. But usually, the smaller the better
I don't think this is good advice.
(1) performance. In languages with a stack, each function is a a new stack frame and another level of indirect. Both dammage cashing and slow the processor
(2) readability. When reasoning about code, too many functions splits and scatters logic meaning one has to jump around to understand what even simple code does. Often its easier to read and recognise a little code patten then having to lookup were its defined and remembering it by name.
(3) premature abstraction. This way of programming lead to writing abstractions around code before youve properly understood the actual problem.
Hi there! While your feedback is welcome, one thing to keep in mind is that software development approaches, languages, etc are just tools. And no tool solves all problems. Yes, this approach may cause a performance penalty, just as it may not. Because of the improvements in both hardware and software, what may have held true a year ago may not hold anymore. A lot of optimizations occur at all levels of the stack so much so that developers now can get away with more than they were once able to. To talk about performance in the abstract may do more harm than good because specifics matter.
Generally speaking, the best way to truly tell if an approach/tool will work or not (performance wise) for a given software project is through profiling.
2) Splitting the code into smaller functions will make it hard to read and think about the logic if the functions are not well named, and they don't truly correspond to a subtask of the bigger problem. Meaning that one should not break down code into sub-functions just for the sake of it. One sign you're doing it right is when you start to realize those same sub-functions can be/are of use in other places (because they each represent a meaningful unit of work). But this is not a hard rule.
3) This is a valid point but still, it does not discredit the approach. This is why. The developer is not forced to apply it from the very beginning, neither is the developer forced to stop when all functions are as small as possible. Again, this is a tool that can and should be applied with thought. Nothing prevents the developer from applying it the moment the nature of the problem and the requirements are solid enough.
So to say it's not good advice is a broad/extreme statement. What it is, is a tool that may/may not work in some situations. But a tool nonetheless.
@@DevToolsMadeSimple thank you for the reply. I will take time later to respond. Till then have a nice day :)
@@DevToolsMadeSimpleBut don't you see that there's overhead to splitting a function into smaller functions? It requires thinking and abstraction on what is not even solved yet so you're likely to do a poor job abstracting it anyways. Why not just abstract when it makes sense and not follow a rule that some guy said? If you can't explain why an abstraction works, you're paying the overhead of doing it and likely making it very hard to modify in the future and harder to read. This may not always be the case, but it often is. I envy the people who seem to magically be able to abstract things, maybe it's a skill issue on my part.
@@DevToolsMadeSimple
Thank you for your reply.
(1) hardware has made incredible advances. We should not squander those hard won gains with self indulgent abstractions, and bad code. It is not hard to make choices that eraise decades of hardware level progress, while not achieving anything that much more impressive then decades old applications. We should focus on building robust, performant and interoperable programs so that our ambition can truly grow as per Gustafson's Law.
@@DevToolsMadeSimple (2) I do believe in writing functions when they are reusable, or for testing pourposes.
I feel strongly about this because my tendency is to do this too aggressively, and I have had to rain this back in and so the advice to break down code as much as possible. Also I find it tremendous annoying when I read other people's code, especially who work in an OO style, were I have to waide through several levels of function calls picking up tiny bits of context in each one.
So when I head "uncle bob" (self styled) give such wide eaching and exstream advice, it strikes a nerve. I remember how I made a c program slower then the python prototype ( that still hurts ), I remember boxing myself into a corner architecturally as I tried to reuse code that should have been inline and spent so much time trying to make the function that code was put into sufficiently configurable to accomplish its usecases. I remember the pain of realising I could have done in 100 lines what I did in 1000 due to this kind of habit.
I got burned coding like this so I don't like his advice
I'm glad this is not so much about inheritance and OOP. More about grouping and structuring by name into "classes". The most descriptive and therefore understandable way to call an API is to explicitely provide all the needed parameters (pure functions). Don't provide them implicitely in the context of the "receiver object", except it is truely internal technical data and therefore some kind of invariant.
All I hear is: add friction to your codebase lol
Large blocks of code are way more unmaintable. Anyone that has worked in large method or classes will remember when the team didn't want to touch it in fear for effecting the remaining 100 lines of code. What if you get an error stack trace didn't give you an exact line. Good luck but in a small method no big deal. When every thing is broken down and properly named it is easier to read and under stand the code base. It reads more naturally. You can dig as deep as you want or stay at a high level when it us broken up while reading. Also good luck unit testing. You will have to write tons if test because of cyclomatic complexity. I could go on there are also architecture effects(rigid) of doing large methods and classes.
So next time you put 5 things on your to-do list for today, make sure you explode them down to the atomic level where you can no longer break them down into subsequent smaller tasks. Only then, when you have about 348 items on your to-do list, with entries like "walk 2 steps" and "pick up pen", then and only then will you know that you've properly organized your day the way it was always meant to be organized. Perfect logic at its finest...
Error, even when you are partially right.
It's not the same organize code than tasks. The program is who, the code is how, the list is what.
Then, you are partially right because ( on GTD, or Atomic Habits, or others books about organization), clearly states the bigger is the task, the most difficutl to manage is. But, if you divide your task on steps, then it is easy to be done. And it is easy becasuse ( at mental level), you are focused on one step at the time (small function). Even, on Atomic Habits states that, sometimes, the task can be "pick up pen", in example, if you what to create the habit for writting or drawing.
Then, at this point, the "atomic code" helps, because if something fails is easy to know where, and fixing it you fix all the places where this function is called. At your life level, you can be concentrate on fix your organization just and exactly where you are failing or missing
That is what people with ADHD are told to do. When they can't get things done.
@@drcl7429 No, the GTD method is implemented by people with high responsabilities, even by CEOs. And the principles described by Atomic Habits have been demostrated by sport champions, and are the psicological base on how we create habits.
If you haven't, i recommend you to read both books.
This is a pet peeve of mine. Right now I'm dealing with a 6k+ line stored procedure and it's horrible!
Uncle Bob is truly a guru when it comes to teaching how to write incredibly unmaintainable ravioli that gets anyone's blood to boil that has to read into such a codebase.
Appropriately atomized code isn't 'incredibly unmaintainable'. Inappropriately atomized code is more likely to qualify for that criticism. The key, then, isn't to throw out the baby with the bath water. Instead, the key is to learn how to **appropriately** atomize code.
if the functions are badly named or have too many arguments it is terrible. Martin, Beck, Fowler and others are quite forthright in telling you name things right and minimise arguments.
If I can reduce a function to 1 line, I make a macro:
#define Sigmoid(x) (1 / (1 + exp(-(x))))
#define SigDer(x) ((x) * (1 - (x)))
As simple as possible and no simpler :)
great advice, until we cannot extract anymore... so we should extract i++ to a function
i = Increment(i);
and there we need to write i = i+1;
or we would run into a recursion until the stack freaks out.
Bobby needs to get out more of his bubble and write some actual production code, but not in python please.
The most importance of code : it should work, do the job required. Customers care how beautiful your code looks ? Sure it shouldn't be an unmaintainable mess, but you can overdo everything.
Second most important thing, always ask where you are allowed to put your curly braces.
Then maybe let someone beautify it, print it out multiple times for security. Then store in a drawer to rot forever.
When AI takes over coding jobs in 20 years, then we will see the worst code ever.
Now AI is very able to copy existing code for snake game #637. But it will only get better, so the marketing team says :)
The time to abstract things that are not going to be reused is a waste.
Unfortunately no one work like this but rather uses excuses to produce unreadable code such as "it is easier to read"
Agreed with everything until he mentioned abstractions. If you habe functions its worth considering the purpose of the function. One purpose is calling other functions. Thing a request handler that calls a validation, sanitisation, then some getData and response function
Hardware Engineers Witnessing the Assassination of Processor Superscalarity
put your whole program in one function
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?
That’s exactly what I told to those junior and they think I am an idiot. They kept in same skill level but promoted as Senior(not promoted by me. I won’t), that’s the reason why we have tons of bad devs on earth. Wrong people who know nothing on what is a good developer is with the right to promote bad developers
Nah. A function is supposed to do something in a sequence. Sometimes it makes sense to have a big function that does one thing after another, spearated by empty lines and comments. You could cut it to pieces or even make a class out of it, but then reading it would be jumping back and forth between small snippets of code, which is even worse for readability.
splitting a function into a class when you could just have had a function is something only a 1990 oop hype guy would come up with 😂
Why stop here? Just create new class for each line of code, that will be even more maintainable or whatever buzzwords he uses.....
A class is a "bunch of variables with a bunch of methods which trates those variables".
If you are, joking, suggesting "Just create new class for each line of code", then you didn't understood the class concept at all and that explains why you failed to understand the video.
@@pablofernandogonzalezolmos8472 The whole code is a "bunch of variables with a bunch of methods which trates those variables".
😂😂😂😂
Thats java
*woosh* that's the point going over your head
I think a lot of the critics here are missing the point. Yes, you could use this concept to an overkill level and be left in a hell of one-line, very explicitly named functions. He’s talking about how to take a program that’s been degraded by years of copy-paste coders and turn it into something actually maintainable. Stop trying to prove him wrong with nitpicky details and consider the effect this could have on someone who regularly deals with 200+ line functions who feels trapped and hopeless.
It's not surprising to see terrible code in production if programmers are as dense as this comment section makes it look. So many people missing the point of what he's saying, it's just sad.
He's so great at C his parents even named him after it
I have many hundred line functions, in C files over 5000 lines long
I once had to work on a code made this way. It's horrible, nearly impossible to get the whole picture. Don't do it. Split your code into semantic things
Atomic functional programming
You are right, but.... I'm lazy
work on simple refactoring now or do more harder work later.
Interesting video ! I have to say that global variables are mostly dangerous. The only value that can be global must be constants
Thank you!
Which is why they are put into classes, right?
They don't stay global, that was just part of being guided towards the "hiding classes", my understanding was that you don't actually make them global, you just "have to make them global" if you extract the functions but before you realize that it should be a class.
@@iron9217 I think you're right. I am not a fan of classes but the concept is clearly that, thanks👍
@@fabricehategekimana5350 So how do you build anything meaningful without classes/structs AND without global variables? Like where is your actual application state stored?
@@zeez7777 good point. Classes aren't the only way to create types but OOP make it looks like it, since its concept doesn't provide this level of understanding🤔
My functions at work are 6000 lines 😂
ironically the code examples shown breaks the cardinal rule of clean code of having self explanatory code. Util classes are always a bad idea.
1 line, if it makes sense.
I wanted to share this with my team but the background music is just TOO cheesy.
there are good places to apply this philosophy but it won't work well if you don't use comments for each one.. trying to keep them under 100 lines is usually a great idea TBH
Wrong! You need less comments. If you use this technique with well thought out names for functions and most variables (iterators get a pass) you will produce self commenting code.
@@drcl7429 correctly formed comments around functions should provide IDE information in popups. long function names get to be pretty long
Make the code documents itself. Clearly you're a kid.
Honestly I don't understand what he was saying. Why is it too fast
Small enough that you don’t need tutorials or have to watch videos.
This is great advice. Ive been following this method for a while to pleasing results.
It’s been a real positive for readability, test ability, and keeping things changeable as a whole.
Hooray for Uncle Bob!
Boo for the silly music!!!!!!!
Isn't the entire point of classes and functions to be reusable? This method of writing them produces no real reusability since they are all specialized for one hyper-specific task. This is just a fancy way of naming blocks of code. At that point just comment the code. If you wrote it well in the first place, you won't need to explain it (this isn't always true, sometimes inelegant code is inevitable).
So let's say I have a guard clause at the beginning of my function, Should that be abstracted away into a separate function? I'm asking in good faith, I want to know how serious should I be about "doing just one thing". What is ONE thing?
Yes, and condition should be in another function. Do you see, how cool is that?
That flies in the face of so much I've been taught. "Make a separate function only when you find an underlying abstraction that can be reused in its general form yadda yadda". I'd like to try it :)
cris wrote, _"What is ONE thing?"_
The video answered that clearly. Did you watch the video?
I do that a lot. It can be read as a sentence.
@@crism8868 How does it fly in the face? It's the same. As he said if you can extract a function then you should extract a function because it was doing more than one thing. That extracted function can always be reused. The argument is often WHETHER it will be re-used .
Can't you find an actually reputable source on code quality, not a grifter who spouts pseudoscience as fact for a living?
Thank you for the feedback. Would you mind showing how and why you disagree with the points in this video?
Sure, I can boost your engagement, small TH-camr trying to get bigger on clickbait figures like Uncle Bob. Because I hope you can actually find someone better for this.
His whole schtick is making things sound as reputable as possible; giving nonsensical historical reasoning because he looks old instead of actual reasons, and having lots and lots of anecdotes. There are never "rules." His point is that what he says is universal, but if you've ever seen him defend his views, he will also backpedal when asked as if he hasn't repeated it as such million times over. All while having a know-it-all attitude that sounds really good to people who don't know any better and enjoy their "Valley of Mount Stupid" of the Dunning-Kruger curve.
He loves insulting the personal reasoning of individuals and their experience to just say "just give them names", as if that makes splicing together single-use functions of 10 lines each to make up what could have been linear code spanning 200 lines of clear and understandable code that is incredibly easy to modify.
In his entire career, he hasn't done anything but talk about programming for a living, while not coding a single thing of actual value. He has (to be fair very skillfully) created a career of false credibility and pure fanboyism that everyone inclined to technically excel should avoid.
There are so many incredibly skilled programmers actually programming on streams, taking you through their entire process demystifying how they achieve incredible productivity and decision making... And we're STILL clipping this absolute clown. Surely you can find someone else.
@DevToolsMadeSimple
@@HaMMeR33661I agree.
To OP, if you want to see this guy defend his ideas, read/watch his dispute with Casey Muratori
@@HaMMeR33661
["In his entire career, he hasn't done anything but talk about programming for a living, while not coding a single thing of actual value. He has (to be fair very skillfully) created a career of false credibility and pure fanboyism that everyone inclined to technically excel should avoid."]
Now this ^ is an extremely bold claim, can you actually prove it?
And also, I find it interesting that, even if hypothetically you where right, it would still mean nothing. Many programmers who used his principles and learned with his methods, someone who said something that can work should be recognized as "producing value" in many senses beside purely by writting code. And while many of your criticisms are valid, and I'm not saying that his methodology is the best or anything, you seem very presumptuous by stating things this way and blatantly dismissing Uncle Bob idea's applications in the software industry.
@@diadetediotedio6918 You're paying attention, good.
I wasn't clear mainly because I'd like the reader to actually go and look for it themselves. So, go and be curious.
I can't really go explain it here -- the mechanisms are very complex. He is a professional at this, you have to understand. His prominence is a calculated effort, and not for his technical skill.
But if I may give you a recommendation, Casey Muratori and his sphere of influence has a very different view on the effectiveness on his methods. GingerBill has a 1hour deepdive on some twitter discourse with relevant techniques pointed out.
If you disagree, you just don't know what I know. You would be surprised what others have to say.
as small as +1, that's what Peano said.
This is actually bad advice... This video doesn't even give have a reason about why you should do what he says to do.. You should only extract code from a function into a new function when there is a real benefit... I don't care if a function is a couple hundred lines if it does what it is supposed to do & is able to be understood. Writing a fuck ton of functions can actually make code harder to read b/c you are jumping all over the file or "files"... To another point, in a large product some code duplication can be NECESSARY... Its not always the best thing for two teams to re-use some code from some other team... Use judgement, make mistakes, refactor mistakes, ship products & live your life.
Big functions can be good. If you only need to do one thing then there is nothing wrong with a big function. I only split things up if I begin to repeat more than once. Functions can be expensive. The problem with "Uncle Bob" and others is that they disregard the FACT that code runs on hardware and that code is not some abstract thing that only matters to those reading it. Clean-code is slow code and one of the main reasons that programs are so much slower today than they were 20 years ago. Slow code nullifies decades of hardware improvements and erases millions of dollars in innovation.
If you are making a library or it is some critical software whose lifespan is 10s of years, then this is definitely good practice to keep tiddy and refactored to the max. But in consumer and fast b2c software this is not at all recommended. Somwthing that you refactored would be thrown away in a brief moment. Useless to spend time on
I wish Uncle Bob would only focus on architecture, not this nitty gritty detail. His work on component analysis and stability is so much more important.
Yeah so... what do you do if you work in C and you don't have your precious classes? Just make everything a global struct?
Sorry but that entire statement is bull.
There is absolutely no reason to split a 6 line functions into two 3 liners just because there is a meaningful way to separate them.
Great, so you now have two functions you call exactly once rather than one. Progress has been achieved, can I please have my salary now.
Like what kind of ideal is that?
Yes, extracting logic from a function and making it smaller is not bad. But only if the function is like 200 lines long, it makes sense to split huge functions like that into smaller groups.
The rule of thumb should be that you should just be able to grasp easily what the purpose of a function is.
That's why I try and keep my functions smaller than 100 lines. You cannot meaningful infer or reason about a 100+ line function, but it is perfectly possible to keep 70 lines of code in your head and see what a function does at one look.
Many programmers seem to forget that source code is a way for the programmer to understand the logic of the program. If you split the program into hundreds of functions you will eventually forget they exist and just have 6 functions do the exact same thing, and while you might have an idea what a 3 line function does, you will not have the slightest idea what that result of the function will be used for 4 functions down the road. So I find that anything below 100 lines does not need to be "meaningfully extracted" into a separate function.
This is what you do in C: you group related functions into different files called "libraries". Each library contains a group of functions, each of those functions should do "one thing". If the one thing they do takes multiple steps, and you see meaning/value in extracting said steps into different functions for the sake of readability/reusability/maintainability then do so. Simple as that. Now some free advice: you might find a function is too big, yet notice that extracting a piece into another function would not be very useful in terms of reusability. In those cases you should extract anyway into a static (aka private) function for the sake of readability. If by doing this, you find that *most* functions fit on the screen and the indentation *almost* never goes past 3 levels youve done it correctly.
Mr Martin has got a bad case of "smelling your own farts"-eosis. This is like feng shui for programmers
But, did anything he said represent an error in his rationale? If not, then it's irrelevant whether he smells his own farts. What are you, some kind of wanna-be comedian?
Extremely opinionated.
you should hear his politics. Total deal breaker.
He sounds like Wallace Shawn
No thanks.
You have turned Uncle Bob into a Transformer
that's the worst suggestion.
Bob spittin’ facts.