Rails modeling guide#2: naming convention for ruby on rails model methods

Naming conventions play an important role to the software's overall architecture. It is not a rocket science, still, it may lead to unhappy consequences if not taken care of at the early stage of a project. This small best practices can make a code base significantly improved.

Rails does a good job by using the dynamic power of ruby and providing with a handful of dynamic methods with the models. ActiveRecord::Base and its included modules follow a consistent naming, which clearly represent the intended purpose of the methods. At Code71, we are working on ScrumPad, a 2nd generation agile scrum tool using ruby on rails and our model methods are named according to the following rules-

1. All boolean returning methods end with '?'

company.billable?, sprint.current?, story.in_progress?

2. Boolean methods do not start with is_ or has_ or did_ (as you might see in other popular languages)

company.is_billable? -> company.billable?
sprint.is_current? -> sprint.current?

3. find_ and find_all are used only for class (self.find or self.find_all) methods and should return a single/array of object of the class respectively.

find_* methods may return a single object of the class/nil

find_all_* methods return an array of objects of the class or [], but never a nil

4. No methods start with a get_ as other languages.

5. A method ends with ! if it alters the object itself.

sprint.close!()
story.progress!()

6. Methods that persists an object/may throw exception, should always end with ! (implied from rule 5)

invoice.update_status!(:paid)

7. Always use parentheses '()' in method names. Future versions of ruby is deprecating the support for method names without parentheses.

Following these 7 simple rules we have consistent and intuitive model method names across the whole ScrumPad. Let me know if you have any suggestion to these names to make it even better.

Rails modeling guide#1: right structure of a ruby on rails model

Rails models are no exception compared to the super models! You are in the business if and only if you got a good physical structure and can stick to it for years...

At Code71, we are keeping our rails models attractive following a few guidelines. I will be posting these guidelines in a series and here goes the first one - about the physical structure of the ruby on rails models.

We keep the following order consistent in our models:-

1. CONSTANTS
2. has_one, has_many, belongs_to, has_and_belongs_to relations in dependency order
3. plug-ins initialization (acts_as_tree, acts_as_state_machine etc.)
4. validates_presence_of
5. validates_uniqueness_of
6. validates_numericality_of
7. validates_format_of
8. custom_validations
9. named_scopes grouped by related purposes
10. active record hooks (after_initialize, before_create, after_create, ...) in execution order in the format (after_initialize [:assign_default_state, :sanitize_content] )
11. protected
12. hook method implementations according to execution order
13. public
14. constructor
15. class methods in alphabetic order
16. other methods alphabetically or grouped if related
17. protected
18. methods alphabetically or grouped if related
19. private
20. self methods in alphabetic order or similar methods in a group
    other methods in alphabetic order or similar methods in a group
    

Rule

No method gets code real estate over 20 lines. If needed, one/more private methods are used.

How is this helping us?

1. We are absolutely sure where to look for a method or where to write a new method.
2. The code base is really consistent.
3. The unit test methods also follow the same order, which makes managing the test suite easy.

More to come later this week. Stay tuned!

Implementing breadcrumb in rails projects – a clean approach

In most web applications, breadcrumbs offer a nice way to trace back to previously visited pages. However, generating the breadcrumbs and showing them on dynamic pages sometimes need special care for the following reasons-

1. The links of the breadcrumb may contain dynamic links.
2. It is used in all the pages. So, changing the breadcrumb may trigger a series of changes.

In ScrumPad, we are using ruby on rails. There are a few plugins to help rails projects in managing breadcrumbs, but none seemed to satisfy our need. In fact, most projects come up with some distinctive ways to generate the breadcrumbs. However, we kept the breadcrumb clean in the following way in ScrumPad.

Step#1:

Encapsulated the breadcrumb generation logic into a single class and used it from all places.

class Breadcrumb
include ActionView::Helpers::UrlHelper
include ActionView::Helpers::TagHelper
include ApplicationHelper

attr_accessor :parts, :separator, :prefix

def initialize(separator = nil, parts = [])
  self.separator = separator || "<img src="\"/images/stub_arrow_right.gif\"" />"
  self.parts = parts
end

def add(title, url = nil)
  self.parts << {:title => title, :url => url}
end

def set_prefix(title, url)
  self.prefix = {:title => title, :url => url}
end

def to_s
  if(!self.parts.nil? and !self.parts.empty?)
    if(self.prefix.nil?)
      parts_with_prefix = self.parts
    else
      parts_with_prefix = [self.prefix] + self.parts
    end
  
    breadcrumb_html = []
    parts_with_prefix.each do |part|
      if(part[:url].nil? or part[:url].empty?)
        breadcrumb_html << "#{part[:title]}"
      else
        breadcrumb_html << link_to(part[:title], part[:url])
      end
    end
    return breadcrumb_html.join(" #{self.separator} ")
  end
  return ''
end
end

Step#2:

A before_filter in the ActionController initializes the breadcrumb in the following way:-

def initialize_breadcrumb()
  @breadcrumb = Breadcrumb.new
  if(project_selected?)
    @breadcrumb.prefix = {:title => "Dashboard", :url => dashboard_project_path(selected_project())}
  end
end

Step#3:

Now, @breadcrumb is available to all actions. However, if the RESTful resource definition is right, the rest of the breadcrumb generation becomes really simple. We have methods like the following in our controllers-

def generate_breadcrumb(sprint, story = nil)
  @breadcrumb.add(sprint.name, project_sprint_path(project.id, sprint.id))
  if(!story.nil?)
    @breadcrumb.add(story.display_title, story_path(story))
  elsif(self.action_name != 'index')
    @breadcrumb.add('Stories', stories_path())
  end

  current_page = self.action_name == 'index' ? 'Stories' : self.action_name.humanize
  @breadcrumb.add(current_page)
end

Step#4:

Finally, in my view layout, I just use this instance variable as shown here:-

<%= @breadcrumb %>

So, the whole breadcrumb generation is encapsulated and the implementation is clean. Let me know if you liked it. I am in the process of creating a plugin so that anyone can just drop it in any rails app and start using straight away!