5 ms·

I don't buy that. The post quoted from _Clean Code_ by Uncle Bob: > The ideal number of arguments for a function is zero (niladic). Uncle Bob is an idiot for

by spc476 5y ago

I don't buy that. The post quoted from _Clean Code_ by Uncle Bob: > The ideal number of arguments for a function is zero (niladic). Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. Just this one statement makes me less inclined to take anything he says seriously.

Jtsummers 5y ago
You're going to judge a book and the man by a context-free quote? That's kind of stupid, you know that right?
- deleted 5y ago
  [deleted]
kleinsch 5y ago
> Uncle Bob is an idiot for making this statement Bold claim for someone who didn't even read the whole quote in context. > The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification-- and they shouldn't be used anyway.
- Silhouette 5y ago
  To be fair it doesn't make any more sense even with the full context. It is just a silly thing to say and it was said without much of a supporting argument at all, never mind any real evidence for the validity of the claim. That is an unfortunately common problem with Clean Code and a lot of other work by Martin.
  - Jach 5y ago
    People get such hate-boners for "Clean Code" specifically, it's weird. I once thought they might have had a point until I read the book and, while I found much to disagree with, it's actually not a bad book (I have more negative things to say about an oft-cited "counter" book, "A Philosophy of Software Design"). I think there's useful things to learn and consider in it, and even though I think you can do better by thinking for yourself, the average bar is so low among programmers that I think many would be improved by substituting their non-thinking flailing around for non-thinking dogmatic following of such books' rules of thumb. Working in such a dogmatic environment would be oppressive, though you at least have a framework to move beyond some of it. Presumably such environments exist and maybe that's a source of some hate, though I've more often seen oppressive environments that e.g. won't accept any Python commits which violate the changing PEP8 lint checks despite PEP8 itself allowing for differences of opinion. There's even more context that people should consider. From earlier in the same chapter: "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small." My relevant point here is that it's clearly not a book full of careful supporting arguments and cited research or really even hyper-specific non-fuzzy rules. It's a style guide for how to make "clean code", built from the author's experiences and idea of what "clean" means. Disagreement is natural, and often also based on nothing more than different experiences rather than careful arguments/research. It's also very contextual, as the book itself notes in places -- different languages, tooling, or emphasized programming paradigms will produce different ideas of what clean means. For the issue about function arguments, in the full context it's very clear that in Java we don't idiomatically interpret the implicit "this" to be an extra function argument as we do in idiomatic Python with its explicit "self". Immediately after the quoted sentence on number of arguments is this: "Consider, for instance, the StringBuffer in the example. We could have passed it around as an argument rather than making it an instance variable, but then our readers would have had to interpret it each time they saw it." That the bytecode for a method using an instance variable includes an "aload_0" instruction to load up "this" and "getfield" to get the instance variable value is an implementation detail. Would it have been better, from a purely functional perspective, to pass the StringBuffer around explicitly anyway? Maybe. Same maybe when it comes to unit testing concerns. Anyway, I don't see much complaining when function bodies make use of implicit built-ins like + or - or sin() or PI, instead of passing all such things as explicit arguments. That way leads to Enterprise FizzBuzz in the Java equivalent. Sure, data not part of the method body has to come from an "outer scope", but this is not "usually a global" but an instance var, and in the very worst is a package-namespaced var. Is it a great sin to lift something into an instance variable? No, not in Java. And even for true 0-arg functions (static methods), the data can come from the method body itself. This is naturally part of the style advocated throughout the book, where you might have e.g. 10 lines of printing out some literal strings (perhaps a little help manual), you can extract those ten lines into a standalone 0-arg static method and the original method will be shorter and cleaner. Edit: one last thing for consideration, Linus has written in the kernel coding style guide "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." Is he an idiot for making such a statement? Is it a silly thing to say?
BeefWellington 5y ago
> Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. You're kind of making the author's point for them here. The entire premise of OO languages is to colocate functionality with the structure of the relevant data for that functionality. If you write a function which takes zero arguments attached to the class Integer (perhaps toString), it does in fact have zero arguments. This makes it simpler to reason about in the context (key word from the point the author was making) of Java. In that context, it is self-evident that any method attached to a class that takes zero arguments is operating entirely on either the data within the class or static data available system-wide. The idea you're presenting is mostly pedantry and you've confused function arguments with data accessible to a function.
scheme271 5y ago
The article itself addresses this in detail at the very beginning. Quoting it a bit: "This statement makes no sense in Haskell (or lambda calculus) since all functions take one argument, and functions with zero arguments are illegal. Does that mean that the ideal function can not exist in Haskell? No, this is an unfair judgment. Uncle Bob wrote this book with an OOP (Object-Oriented Programming) perspective with examples in Java. The point is that many arguments can be hard to use, understand, and can be a smell of too many dependencies. "
cush 5y ago
A simple “no” would have sufficed.

by spc476 5y ago

Jtsummers 5y ago

You're going to judge a book and the man by a context-free quote? That's kind of stupid, you know that right?

deleted 5y ago
[deleted]

kleinsch 5y ago

> Uncle Bob is an idiot for making this statement Bold claim for someone who didn't even read the whole quote in context. > The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification-- and they shouldn't be used anyway.

Silhouette 5y ago
To be fair it doesn't make any more sense even with the full context. It is just a silly thing to say and it was said without much of a supporting argument at all, never mind any real evidence for the validity of the claim. That is an unfortunately common problem with Clean Code and a lot of other work by Martin.
- Jach 5y ago
  People get such hate-boners for "Clean Code" specifically, it's weird. I once thought they might have had a point until I read the book and, while I found much to disagree with, it's actually not a bad book (I have more negative things to say about an oft-cited "counter" book, "A Philosophy of Software Design"). I think there's useful things to learn and consider in it, and even though I think you can do better by thinking for yourself, the average bar is so low among programmers that I think many would be improved by substituting their non-thinking flailing around for non-thinking dogmatic following of such books' rules of thumb. Working in such a dogmatic environment would be oppressive, though you at least have a framework to move beyond some of it. Presumably such environments exist and maybe that's a source of some hate, though I've more often seen oppressive environments that e.g. won't accept any Python commits which violate the changing PEP8 lint checks despite PEP8 itself allowing for differences of opinion. There's even more context that people should consider. From earlier in the same chapter: "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small." My relevant point here is that it's clearly not a book full of careful supporting arguments and cited research or really even hyper-specific non-fuzzy rules. It's a style guide for how to make "clean code", built from the author's experiences and idea of what "clean" means. Disagreement is natural, and often also based on nothing more than different experiences rather than careful arguments/research. It's also very contextual, as the book itself notes in places -- different languages, tooling, or emphasized programming paradigms will produce different ideas of what clean means. For the issue about function arguments, in the full context it's very clear that in Java we don't idiomatically interpret the implicit "this" to be an extra function argument as we do in idiomatic Python with its explicit "self". Immediately after the quoted sentence on number of arguments is this: "Consider, for instance, the StringBuffer in the example. We could have passed it around as an argument rather than making it an instance variable, but then our readers would have had to interpret it each time they saw it." That the bytecode for a method using an instance variable includes an "aload_0" instruction to load up "this" and "getfield" to get the instance variable value is an implementation detail. Would it have been better, from a purely functional perspective, to pass the StringBuffer around explicitly anyway? Maybe. Same maybe when it comes to unit testing concerns. Anyway, I don't see much complaining when function bodies make use of implicit built-ins like + or - or sin() or PI, instead of passing all such things as explicit arguments. That way leads to Enterprise FizzBuzz in the Java equivalent. Sure, data not part of the method body has to come from an "outer scope", but this is not "usually a global" but an instance var, and in the very worst is a package-namespaced var. Is it a great sin to lift something into an instance variable? No, not in Java. And even for true 0-arg functions (static methods), the data can come from the method body itself. This is naturally part of the style advocated throughout the book, where you might have e.g. 10 lines of printing out some literal strings (perhaps a little help manual), you can extract those ten lines into a standalone 0-arg static method and the original method will be shorter and cleaner. Edit: one last thing for consideration, Linus has written in the kernel coding style guide "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." Is he an idiot for making such a statement? Is it a silly thing to say?

BeefWellington 5y ago

> Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. You're kind of making the author's point for them here. The entire premise of OO languages is to colocate functionality with the structure of the relevant data for that functionality. If you write a function which takes zero arguments attached to the class Integer (perhaps toString), it does in fact have zero arguments. This makes it simpler to reason about in the context (key word from the point the author was making) of Java. In that context, it is self-evident that any method attached to a class that takes zero arguments is operating entirely on either the data within the class or static data available system-wide. The idea you're presenting is mostly pedantry and you've confused function arguments with data accessible to a function.

scheme271 5y ago

The article itself addresses this in detail at the very beginning. Quoting it a bit: "This statement makes no sense in Haskell (or lambda calculus) since all functions take one argument, and functions with zero arguments are illegal. Does that mean that the ideal function can not exist in Haskell? No, this is an unfair judgment. Uncle Bob wrote this book with an OOP (Object-Oriented Programming) perspective with examples in Java. The point is that many arguments can be hard to use, understand, and can be a smell of too many dependencies. "

cush 5y ago

A simple “no” would have sufficed.