Consider seeing this code in a view. It seems a little long, and may be a candidate for refactoring. Lets see how we can make it better.
<%= event.ticket .custom_message .to_s.strip .gsub("[URL]", site_url) %>
One way to rewrite this is to make it as short as possible, ie, store all the complexity in a helper function. In my opinion, this isn't really ideal for the following reasons:
<%= custom_message_for(event) %>
def custom_message_for(event) event.ticket .custom_messag .to_s.strip .gsub("[URL]", site_url) end
Same complexity, new location. The complexity was simply moved from one part to another, instead of broken down into more easily-understandable chunks.
Tight coupling. The method
custom_message_for is too tightly coupled. To test this, you will need to create a mock event, with a mock ticket, with a mock custom message.
I would prefer this to be written as a helper that takes in a string, such as so. The view code may be a little longer, but you get these advantages:
def format_message(message) message.to_s.strip.gsub("[URL]", site_url) end
Simple and obvious. The method
format_message is simple and its purpose is immediately obvious.
Understandable at a glance. Glancing at the view code (
format_message(event...)), it's apparent how the message is being derived.
Easy testing. It can be easily tested—just need to pass it a string.
Another way to implement this is with a presenter, which may not be a bad idea either.