Code Organization

Use a code editor with Rubocop enabled. Ensure that your setup generally matches the DHH version of Rubocop.
Opt for Factories instead of big controllers, particularly for complex actions. Creating and deleting items often will use factories in lieu of complex interactions in controllers. (i.e. keywords_factory).
A Class should have a single argument, args, which should be set to an args or args hash that as attr_readable. Then, the parameters of this options hash should be exposed as methods on the class. This keeps the class flexible, and allows us to add parameters without having to redefine the interface anywhere.
Complex items where you have 3 or 4 attributes on a method, and 20 or 30 lines of code, should be refactored into their own classes. Opt for a new class in lieu of a complex method when in doubt.
Comment each method with at least 1 line of code about what it does. If its complex, or performs a complex interaction, explain what the method does above the method in comments.
If a class has more than 200 lines, it might need to be refactored into smaller classes. Often, larger items should be broken into smaller items so that each class can do 1 thing. These are also easier to document and test, and provide reusable hooks.

Last updated 7 years ago

Use a code editor with Rubocop enabled. Ensure that your setup generally matches the DHH version of Rubocop.
Opt for Factories instead of big controllers, particularly for complex actions. Creating and deleting items often will use factories in lieu of complex interactions in controllers. (i.e. keywords_factory).
A Class should have a single argument, args, which should be set to an args or args hash that as attr_readable. Then, the parameters of this options hash should be exposed as methods on the class. This keeps the class flexible, and allows us to add parameters without having to redefine the interface anywhere.
Complex items where you have 3 or 4 attributes on a method, and 20 or 30 lines of code, should be refactored into their own classes. Opt for a new class in lieu of a complex method when in doubt.
Comment each method with at least 1 line of code about what it does. If its complex, or performs a complex interaction, explain what the method does above the method in comments.
If a class has more than 200 lines, it might need to be refactored into smaller classes. Often, larger items should be broken into smaller items so that each class can do 1 thing. These are also easier to document and test, and provide reusable hooks.

Last updated 7 years ago