Read a style guide

[weathertopper]

You slob.

[weathertopper]

With this, rewatch Derek Banas' videos for RoR. He explains some key features that Rails does auto-magically to re-use form code.

[weathertopper]

Also, I know there's a way for the routes file to do most of the work for me as opposed to me writing out all of the obvious routes.

[weathertopper]

Some reading: https://github.com/bbatsov/rails-style-guide https://github.com/bbatsov/ruby-style-guide https://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices http://www.pragtob.info/rails-beginner-cheatsheet/

[weathertopper]

This comment is going to be my go-to for note-taking:

• iteration

  
  # bad
  Person.all.each do |person|
  person.do_awesome_stuff
  end

Person.where('age > 21').each do |person| person.party_all_night! end

good

Person.find_each do |person| person.do_awesome_stuff end

Person.where('age > 21').find_each do |person| person.party_all_night! end

- Look at persistence to see how to NOT wipe out data bases ( I think) 
- Avoid string interpolation in queries, as it will make your code susceptible to SQL injection attacks. 

bad - param will be interpolated unescaped

Client.where("orders_count = #{params[:orders]}")

good - param will be properly escaped

Client.where('orders_count = ?', params[:orders])

- Consider using named placeholders instead of positional placeholders when you have more than 1 placeholder in your query. 

okish

Client.where( 'created_at >= ? AND created_at <= ?', params[:start_date], params[:end_date] )

good

Client.where( 'created_at >= :start_date AND created_at <= :end_date', start_date: params[:start_date], end_date: params[:end_date] )

- Favor the use of find_by over where and find_by_attribute when you need to retrieve a single record by some attributes. [link]

bad

User.where(first_name: 'Bruce', last_name: 'Wayne').first

bad

User.find_by_first_name_and_last_name('Bruce', 'Wayne')

good

User.find_by(first_name: 'Bruce', last_name: 'Wayne')

- Favor the use of find_by over where and find_by_attribute when you need to retrieve a single record by some attributes. [link]

bad

User.where(first_name: 'Bruce', last_name: 'Wayne').first

bad

User.find_by_first_name_and_last_name('Bruce', 'Wayne')

good

User.find_by(first_name: 'Bruce', last_name: 'Wayne')

- Never call the model layer directly from a view.
- Never make complex formatting in the views, export the formatting to a method in the view helper or the model.
- Mitigate code duplication by using partial templates and layouts
- No strings or other locale specific settings should be used in the views, models and controllers. These texts should be moved to the locale files in the config/locales directory. [link]
- When the labels of an ActiveRecord model need to be translated, use the activerecord scope: [link]

en: activerecord: models: user: Member attributes: user: name: 'Full name'

- Then User.model_name.human will return "Member" and User.human_attribute_name("name") will return "Full name". These translations of the attributes will be used as labels in the views.
- Separate the texts used in the views from translations of ActiveRecord attributes. Place the locale files for the models in a folder locales/models and the texts used in the views in folder locales/views.
- When organization of the locale files is done with additional directories, these directories must be described in the application.rb file in order to be loaded.

  # config/application.rb
  config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]

- Place the shared localization options, such as date or currency formats, in files under the root of the locales directory. [link]
- Use the short form of the I18n methods: I18n.t instead of I18n.translate and I18n.l instead of I18n.localize. 
- Use "lazy" lookup for the texts used in views. Let's say we have the following structure: 

en: users: show: title: 'User details page'

-The value for users.show.title can be looked up in the template app/views/users/show.html.haml like this:

= t '.title'

- Use the dot-separated keys in the controllers and models instead of specifying the :scope option. The dot-separated call is easier to read and trace the hierarchy. 

bad

I18n.t :record_invalid, scope: [:activerecord, :errors, :messages]

good

I18n.t 'activerecord.errors.messages.record_invalid'

- Reserve app/assets for custom stylesheets, javascripts, or images. 
- Use lib/assets for your own libraries that don’t really fit into the scope of the application.
- Third party code such as jQuery or bootstrap should be placed in vendor/assets. 
- When possible, use gemified versions of assets (e.g. jquery-rails, jquery-ui-rails, bootstrap-sass, zurb-foundation).