use dashes (-) for branches, it's easier to write than underscore (_)
- pull latest changes in the master branch git checkout master git pull origin master
- checkout on-your-feature git checkout my-feature
- use rebase -i master git rebase -i master
- stash all your commits except the first one
- write a explicit commit associated to the pivotal feature
- in the comment write: [Finishes #id-of-the-feature-in-pivotal]
- a value object (ex: territory_coverage)
- an answer to a question (ex: executed?)
- order dates
# scope :newest_first
# scope :latest_first
scope :new_first # default order
scope :newly_created_first # "newly_{attr}_first" add field inside for specific ordering
scope :old_first
scope :older_created_first
# scope :recent
# scope :least_recent
# scope :recently_sent
# scope :least_recently_sent-->
# scope :chronological
# scope :rev_chronological
- order names
scope :alphabetic
scope :rev_alphabetic
- filter by type
scope :from_commentable, ->(commentable) ...
- filter by status
- find alike: class method that retrieve one object (using first)
- given a polymorphic association
def self.find_by_commentable(commentable)
- prefer to call a class method (other than ::new) to initialize or execute action an object when outside of the file
ex:
module RightsUp
module Tracks
class Destroyer
def self.execute(track)
new(track).destroy
end
...
end
end
end
- prefer to hide sub-namespaced classes with an easy external api
ex:
module RightsUp
module Tracks
def self.destroy(track)
Destroyer.execute(track)
end
end
end
- Methods should not hold more than 3 instructions unless it really make sense. Extract private methods until you cannot any more! (Extract until you drop).
- Implement only what you need
- Test only what need to be tested
- The readability of tests is as important as the readability of production code.
@SimonMiaou quel est ton avis sur le choix des scopes ?