much to quite a few people's disappointment. I've decided to learn Ruby on Rails (I've been told by many people it's pointless to learn it, but ruby seems easy to get into and rails is a fun framework).
So I'm just now slowly starting to wrap my head around the naming convention with singular being used for the model and plural being used for the controller.
One thing I'm having a bit of trouble finding concise information on is Capitalization vs lowercase usage.
Example being
#order = Order.create(order_date: Time.now, customer_id: #customer.id)
Why exactly is 'Order.create' capitalized but not 'order_date'?
When to invoke capitalization has really got me confused when I use the rails console. I don't know when I'm suppose to be capitalizing or why. I want to say it too has to do with the model/controller naming scheme but neither of them are plural so that can't be the answer right?
Thanks for any help that is given, I really would/do appreciate it.
CamelCase is used for classes and modules (e.g. String, Array, etc.)
snake_case is used for variables and methods (symbols are also usually snake_case)
SCREAMING_SNAKE_CASE is used for naming constants (e.g. STDOUT)
This is to do with naming conventions in Ruby and/or Rails.
Typically:
Create classes, modules using CamelCase.
Create methods, variables using underscore_case.
Create constants using UPPER_UNDERSCORE_CASE.
Take a look at different methods available in ActiveSupport to convert a string into various cases. http://apidock.com/rails/v4.1.8/String/camelize
Read Naming and Schema Conventions at Rails Guide.
A more succinct information.
HTH
This is more a ruby thing actually. In ruby you use capitalization (camel case) for class and module names. And snake_case for method and variable names.
In your specific case Order is a class, create is a method, #order is an instance variable. order_date and customer_id are symbols that represent the columns on the database.
Related
How much of this is auto-generated methods in Rails "User.find_or_create_from_auth_hash(auth_hash)". That is just wondering how this works, and what would have been the minimum coding the dev would have to do? That is, what method would they have had to implement in the User model? or would they need a method named exactly that. So just wondering if the "find", "create", "from" keywords are Rails specials here.
Taken from here: https://github.com/intridea/omniauth
Rails provides the dynamic finders find_by_*, find_or_initialize_by_*, and find_or_create_by_* via method_missing for each attribute of your model.
The self.find_or_create_from_auth_hash(auth_hash) method however isn't at all provided by rails and is simply using the same type of naming conventions for readability.
EDIT:
Apparently it also provides find_last_by_* and find_all_by_* as well. I've personally never used them though.
I am using Ruby on Rails 3.1 and I would like to know how, when and why I should use one of the following code rather than another on internationalizing my application (I18n gem):
t(:test_key)
t('test_key')
t('.test_key')
That is, what is the "subtle" difference between using t(:test_key), t('test_key') and t('.test_key')? What are best practices about this issue?
I think first two are equivalent and you just refer to main key in your translations, fo example
t('hello_world')
# t(:hello_world) is an equivalent
would reffer to
en:
hello_world: "Hello world"
However if you use dot notation, its called lazy lookup
and it will look deeper in your translation structure based on controller/action notation
So if you use this inside users/index template
t('.hello_world')
it will be resolved to
pl:
users:
index:
hello_world: "Witaj świecie"
You'll find more about internalization in Rails Guides
I guess it's a but up to you to decide when you actually want to use the different ones, but I'd prefer to use lazy lookup as much as possible in my views, unless you need to translate some generic component whose keys does not live in the scope of your view.
The reason why I prefer the lazy lookup is that it makes the code look cleaner, and as long as you're familiar with how the i18n gem works, you shouldn't have any trouble knowing where to look for the keys.
On the other hand, if you have such components, they should really live in a partial, a cell or something similar.
One thing worth mentioning abouth the non-lazy ones, are that you can provide them with a scope for where to look for the key in question. Again, it's up to you whether you like t('foo.bar.baz.test_key') or t(:test_key, :scope => 'foo.bar.baz').
It also takes a bunch of other options, but all of this is neatly documented in the rails guide, so I won't explain it further here.
How should I name a action if it contains 2 words:
word_other
wordOther
wordother
?
I assume you're talking about controller actions? In that case, they need to be underscored: get_user.
The convention is for variable and method names to be underscored: #new_instance.get_user. This ensures that controller methods map cleanly to actions. It also improves readability and helps distinguish method_names from ClassNames
In Ruby, method names have the convention that they should be separated by underscores, so Rails action names are no different.
It should be with underscore: word_other.
Rails action name is actually just a method name and Ruby's convention for method name is in lower case with words separated by underscore.
I was trying to find an official statement about this, but unfortunately I couldn't find it. But you can have a look at the methods available in Ruby Core to see how Ruby methods are named. There's also a write up on the naming convention for both Ruby and Rails.
With Rails, naming convention is even more important because one of the philosophy of Rails is convention over configuration. For example, if your controller class name is BookShopsController, you need to use book_shops to refer to it in your routes.
resources :book_shops
# or
match 'book_shops/:id' => 'book_shops#show'
If you don't follow along with the convention, you may find that things are more difficult to work with or it may not work as expected.
You should name it word_other.
In short:
methods and variables: all_lower_case_seperated_by_underscores
class- and module-names: CamelCased
constants: UPPERCASE
This article is very good summary of the ruby and rails naming conventions.
In general, ruby identifiers should use snake_case rather than camelCase. However, Rails action names should be selected from a much smaller list: show, index, new, create, edit, update, destroy. That is to say that following RESTful conventions will lead you to a simpler system that more accurately reflects the semantics of the web and allows you to more cleanly model your domain's resources and should be preferred to other action naming 'systems'.
I'm writing a rails application, and I need to name one of my model Test, and inside that model I need a class attribute - when I tried the first one, I couldn't run any UT since Test ceased to be a module - so I ranamed to Tst. I haven't even tried naming a column class - I went with clss. What names would you use? Are there any conventions known amongs RoR developers for such situations?
I haven't seen anything for Test but class is typically changed to klass.
Ruby and Rails have several different objects part of a standard library. You cannot use an already-defined class name as name for your models.
For instance, you cannot call a model Thread or Object because Ruby already defines a Thread and Object class.
Likewise, Ruby has a library called Test::Unit so you can't use the Test namespace as model name.
There isn't a real full list of reserve objects because it really depends on your current environment. However, in order to successfully use Rails, you should at least have a basic Ruby knowledge so that you know the names of the most common standard library classes.
I've run up against this a few times (writing educational software--where you regularly want to model 'tests' :-). Depends exactly what you're modeling I suppose, but I usually opt for 'quiz' to avoid conflicts. I'd love to hear a better solution, since I find 'quizzes' an awkward plural.
Like dj2 said, class is usually done as 'klass'.
Please check the following page for Rails reserved words: http://reservedwords.herokuapp.com/ None of these words should be used as class or attribute name.
Not sure what the difference between underscore (student_state) and tableize (student_states), other than tableize also pluralizes. However, not sure how they can be used
differently. Obviously, you can use tableize to reference table name in
database. But what different functionality does underscore provide, such as when you see :student_state compared to :student_states when used as symbols. Thanks for suggestions.
tableize will pluralize your string whether the original was singular or plural, while underscore will only add underlines.
While this may seem trivial, it's all about abstracting the details of database implementation away from the developer. If, down the road, Rails began formatting table names differently, the only method that would need to change would be tableize. All other places in the Rails code that refer to table names can stay the same, because they're still calling the tableize method. A change to the underlying structure of rails is therefore limited and much less damaging.
This is referred to as "orthoganality" in computer science. Now that you know what it means, try to throw it around in conversation to make yourself look smarter. Did it work for me? :)