Posted by
guolei
on
May 31, 2011
When the business logic of models becomes complex, it's very helpful to keep a consistent code structure that is agreed by team members.
Following Rails conventions, life is happy. It can be happier if we create conventions for codes in models, especially when there's multiple programmers working on the same model.
One example: (From top to bottom)
- associations
- scopes
- class methods
- validates
- callbacks
- instance methods
Code example:
class Article < ActiveRecord::Base
has_many :comments
belongs_to :author
default_scope order("id desc")
scope :published, where(:published => true)
scope :created_after, lambda{|time| ["created_at >= ?", time]}
class << self
def batch_create(data)
# ...
end
end
validates :title, :presence => true
before_create :init_score
def init_score
self.score = 10
end
def any_instance_method
# ...
end
begin "score related functions" # Group functions by begin .. end
def add_score(score)
# ...
end
end
end
Comments
Also i tend to avoid the
class << selfnotation just for defining class methods, i prefer to use the more explicitdef self.mymethodbecause then there's no chance to confused a class method with an instance methode...particularly when you have a few class methods and you scroll down below the << definition.1.associations
2.validates
3. constants
4.scopes
5.callbacks
6.class methods
7.instance methods
8. private or protected methods
Questions:
Where would class level variables go?
Would Accessors go just before the class methods?
Also, (if this is considered a good practice), where would instance variables go?
thanks,
Dave
For your questions, I'd like to put class level variables on the top of the class and accessors go just after (or before) that.(Many examples can be seen in rails source code) If instance variables needed, I suggest put them after class variables.
class MyModel < ActiveRecord::Base
serialized attributes
CONSTANTS
scopes
relationships
attribute accessors
gem configurations e.g., acts_as_authentic
validations and callbacks
class methods
instance methods
protected/private methods
end
i argue for scopes over relationships because scopes are class methods and relationships are instance methods. also, relationships are so common that i often know how they work without having to open them. scopes on the other hand have need slightly more referencing and therefore it's nice to be reminded of them when first opening the file.
Something configurable with your preferred order like
#
...
#
#
...
#
etc.
# [associations]
...
# [/associations]
# [scopes]
...
# [/scopes]
etc.
2.scopes
3.validates
4.callbacks
5.class methods
6.instance methods
I like this because validates & callbacks 's codes are sort and clean. It is in goog order.
https://gist.github.com/1014971
If I get one of each element and that it concerns a given subject I should put it in a concern ? Ok then what's the point ? My model is empty and my concern is full, yipee...
Concerns should be used when necessary, not just as a way to go. Concerns are cool to organize a complex model that has several features defined.
BTW, concerns are not related to the subject, we are talking about code order and in a concern, the question is the same, in which order would you place your code...