Sandi Metz' Rules For Developers

[worace]

Discuss Sandi Metz's Rules for Developers here. Which of Sandi's rules do you feel like might be the hardest to follow—why?

[kristinabrown]

I think the hardest of Sandi's rules to follow is the 5 lines per method. Forget about conditionals, they take up a lot of lines and someday I will learn how to code without those, but even controller methods like create and update, are above 5 lines, easily. If you have a happy path, a sad path, maybe a flash message or two, and a redirect or a render you're looking at 8 lines.

[Carmer]

My first impression of things was that violating the 5 lines per method would be difficult. But, after a little thought, I think the hardest of Sandi's rules is to only instantiate one object in a controller. The reason I changed my mind is because with a little abstraction we can easily cut down out lines of code per method. The example Kristina game above about controller methods often being over 5 lines is a good example. More often than not out controller have a happy path and a sad path, but they are very similar no matter what controller action you are going through. So I think we could abstract the happy path and sad path out into their own methods in which case we can pass through different flash message and path to the method (as long as we keep it under four arguments). The reason I think only instantiating one object per controller is difficult is because we often need multiple objects in our views. Maybe we need to access a user and their blog posts, or an item and it's category. According to Sandi's rules we cant even user @user.posts or @item.categories. So, how do we not violate the rule? The article we read gives a good work-around, facade pattern, which I think is a cool way to solve this problem. Whenever you need an additional object you can just add it to the facade and viola - you have access in your view. However, making a whole facade is a lot of extra code if all we need is one thing from the secondary object.

[michelleambrisco]

I agree with Andrew, as I was working this past weekend I had those rules in the back of my mind and could not think of how to follow the 'one object in a controller' rule. My one controller had lists and tasks and users and the lists and tasks were necessary for the view. I like also ended up writing a lot of private methods to try to follow the five lines per method rule which was a good challenge.

[tessgriffin]

I agree with Andrew as well about the instantiating one object in the controller. It was interesting in Caleb's example on the blog that he had a dashboard "facade" and that's what he used to pass to the view. I guess he was using the facades as kind of a plain old ruby object to compartmentalize that dashboard view. I think at first it would be hard to put that logic into something like that rather than in the controller.

[tleskin]

Same with me. I was thinking about how I would do this before reading the section on instantiating one object in a controller. I thought the example was interesting on how they created the dashboard class and passed the dashboard's state to the view partials. It'd be interested to look back at our past projects and see if we could refactor them to do keep with all these rules. I think my team's Dinner Dash would be an interesting challenge for that.

[NYDrewReynolds]

I agree with Kristina. I think the hardest rule to follow would be keeping methods to only 5 lines. While I think it is much more doable in Ruby, this idea would be very difficult in Rails. There is so much information that needs to be passed to different components. What actions are we taking in methods such as create? What relationships does this new object have & do we have to make that association here? What action do we take upon success or failure? Now that we have that information, what page would you like us to render/redirect to?

Trying to accomplish all of these goals with only 5 lines would require developers to break out this logic into other methods which could end up being uglier & more confusing.

[with-a-k]

I'm kind of torn between "five-line methods" and "only make one object in the controller". I don't understand the facade concept mentioned in the article, but limiting the amount of control flow you can use by that much doesn't seem feasible.