Code-Style-Guide

code-style used around the project must be respected
1. private methods should be prefixed with an underscore (_)
for each model, Associations, Scopes, Security, Validations modules have to be created (when needed)
try to group migrations by logic/model similarity. For example, if you're adding a column on a model created in the same PR, rollback the migration ad edit it. PLEASE NOTE that migrations must be backward compatible, and that we stick on migration that can be executed after deploy.
selectively commit schema.rb, including only branch-related changes. If there are no database changes, schema.rb changes shouldn't be pushed
changed code has to be backward compatible, clients can't be updated on-the-go as backend can
if changes treat money, use monetized fields and take care of _cents notation. _cents column must have null: false and default: 0
for any doubt on code, check around the code and on the internet for 10 minutes before asking for help
document the methods using yard markup format and as suggested by Jeff Atwood:
1. Keep comments as close to the code being described as possible. Comments that aren’t near their describing code are frustrating to the reader and easily missed when updates are made.
2. Don’t use complex formatting (such as tables or ASCII figures). Complex formatting leads to distracting content and can be difficult to maintain over time.
3. Don’t include redundant information. Assume the reader of the code has a basic understanding of programming principles and language syntax.
4. Design your code to comment itself. The easiest way to understand code is by reading it. When you design your code using clear, easy-to-understand concepts, the reader will be able to quickly conceptualise your intent.
For migrations that populate or update records, see maintenance tasks
Escape % characters when submitting input to LIKE/ILIKE searches, e.g.:
```
where('name LIKE ?', "%#{sanitize_sql_like(value)}%")
```