Hacker News Reader

Comment by grannyg00se | Hacker News Reader

I'm reading Clean Code (again). I dont see that code as being particularly bad. But it definitely wouldnt follow the axioms in that highly regarded book. I realize it isnt java but can someone familiar with the text comment on the number of parameters in that function and the naming of some of those variables?

Relevant quote: "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 justiﬁcation—and then shouldn’t be used anyway."

View on HN

Zero? So not even pure functional programming is OK, since that tends to pass state as function arguments? We should all just happily poke our global state from our niladic functions?

Haven't read that book, but color me neon skeptical.

Well POSIX requires more than three arguments for some system calls. But around 6 is the limit for most architectures. They are passed in registers for efficiency.

So, the function in question operates on a socket object. In Java that would be implicit as the object on which you invoke the method, but in C it must be an explicit function argument - that accounts for the first `fd` parameter.

The second mmsg parameter points to an array of compat_mmsg objects. In C, the array length must be passed as a separate parameter, so the second and third parameters are really one logical array parameter.

I find the idea that the ideal function takes no arguments to be astonishing. There are only two kinds of functions that take no arguments:

1. Those that return the same result every time.

2. Those that mutate some internal state (or, roughly equivalently, those that inspect internal state being mutated elsewhere).

#1 isn't all that useful in general, although there are obviously cases where it's exactly what you want. For #2, while state is useful at times and a necessary evil in many other cases, it's hardly ideal.

Even a single parameter seems decidedly un-ideal. To do useful work in general, you're typically going to want to take two parameters: something to be modified, and the modification to make. This can be done with state (modify in place) or functionally (return a new object with the modifications applied). Once again, having a single argument seems to imply either something not very useful (basically a getter or some similar derive-a-value function) or something relying on mutable state. You need two arguments to achieve the sort of combinatorial power that makes functions interesting and properly useful.

I wonder if the book, which I assume is talking about Java, is ignoring the implicit zeroth argument which is the object you're invoking the function on. Obviously in C you have to make that parameter explicit, but I've got enough experience of both languages to know that people often don't consider the object to be a parameter to one of its member functions.

So if you're converting that rule back to C, you'd need to add one to each element of the rule. The one parameter rule is saying that when special cases are common, a special function to handle it is a good thing. So writing `i++` rather than `i = i + 1` or `next(node)` rather than `skip(node,1)`.

That would make sense, except for the part where Java doesn't have functions at all, but rather methods. I imagine you could call them functions, but I haven't seen it done, and that sort of terminology sloppiness leads exactly to confusion like this.

Thanks for the responses. The text is definitely referring to Java methods as functions, and not counting the implicit object instance (this) as a parameter. The text also considers multiple parameters of the same type that are treated identically as lists counting as one parameter.

Appreciate the clarification. The advice sounds much more sane that way. It sounds like a terribly confusing way to put it, but maybe it's better in context.

Reply on news.ycombinator.com