What do you think about `private def … end`?
Recently I was told that “too bad Ruby doesn’t support private def … end because it forces us to put related methods far from each other.”
But it actually does because work because def returns a method name and private can take one. Therefore it is possible to write this code:
class Article
def title
something_complicated
end
private def something_complicated
'Hello'
end
def id
5
end
end
Instead of:
class Article
def title
something_complicated
end
def id
5
end
private
def something_complicated
'Hello'
end
end
Do you use this trick? Or do you consider it non-Ruby style? Is clear separation of visibility more important than locality? Personally I’m on par with this.
Note: I did not want to post this elsewhere but am interested in comments and this system requires a link, so here it is: http://apod.nasa.gov/apod/ap151020.html
Comments
I know about it, but I don’t use it. The conventions are more important for me. There might be good use cases for it sometimes though.
Avdi Grimm mentioned this in one of his early Ruby Tapas videos and I’ve been using it occasionally since then. It became available in Ruby 2.1 (previously method defs returned nil). I use it when I want the private method near a related method in the source. If I have a block of private methods I’ll use the old style.
The problem with use
privateisolate and the methods below it’s fact to be complicate localize where methods private beginning, but I think that your class has so private methods impossible to see where started, it’s a clear problem about design code.IMO whatever what approach you work, because if you have a good design, both would easy to identify.
I think the key question is, “Does this make all my code more readable?”
It will make the comprehension of your top-level public method (in this case
title) that little bit easier, that’s for sure. But what about comprehension of your class as a whole? If you have several public methods which are intermingled with lots of private ones, that could make it harder to grasp the top-level interface of your class.If your public method calls private ones, then make sure they’re named descriptively and clearly. Reading the public method should make it clear what is happening and why. Then, below your top level methods, you place all the methods that they call, again making sure that the code is descriptive, and any further methods they call are named to correctly describe what they do. And so on. In Ruby, this will tend to mean that you only need the private declaration once, near the top of the file – so your class’s intent is fully clear above that line, and yet anybody who needs to understand the code in more detail can read from top to bottom and find their knowledge of what your code does expand from an outline.
In Clean Code, Robert C Martin describes this as the Stepdown Rule, and it’s a principle which I’ve found makes my code more readable.
Thank you all for the replies. Looks like it all boils down to how the code is organized and if it’s a kitchen-sink, then neither of the approaches will work.
Post a comment