Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Recategorize some styles into best practices, protocol

* Attempt to keep styles as conventions, formatting, organization
* Move workflow rules into protocol
* Move practices that go beyond formatting into best practices
commit 89f6def6a3a371e2848fbee7bd6ccba756946043 1 parent a1b0396
Joe Ferris jferris authored
Showing with 36 additions and 28 deletions.
  1. +26 −0 best-practices/README.md
  2. +10 −0 protocol/README.md
  3. +0 −28 style/README.md
26 best-practices/README.md
View
@@ -54,9 +54,25 @@ Rails
`update_attribute`, and `toggle`.
* Don't change a migration after it has been merged into master if the desired
change can be solved with another migration.
+* Don't reference a model class directly from a view.
+* Don't use SQL or SQL fragments (`where('inviter_id IS NOT NULL')`) outside
+ of models.
+* If there are default values, set them in migrations.
+* Keep `db/schema.rb` or `db/development_structure.sql` under version control.
+* Use SQL, not `ActiveRecord` models, in migrations.
+* Use `_path`, not `_url`, for named routes everywhere except mailer views.
* Validate the associated `belongs_to` object (`user`), not the database
column (`user_id`).
+Testing
+-------
+
+* Avoid `its`, `let`, `let!`, `specify`, `before`, and `subject` in RSpec.

Hi @jferris,

May I ask why 'let' is harmfull in RSpec?

Joshua Clayton Admin

@orbanbotond We've written a blog post which outlines why we avoid most of these here: http://robots.thoughtbot.com/lets-not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+* Avoid using instance variables in tests.
+* Use an `it` example or test method for each execution path through the method.
+* Use [stubs and spies](http://goo.gl/EciDJ) (not mocks) in isolated tests.
+* Use a single level of abstraction within scenarios.
+
Bundler
-------
@@ -107,6 +123,16 @@ Testing
* Use integration tests to execute the entire app.
* Use non-[SUT](http://goo.gl/r5Ti2) methods in expectations when possible.
+JavaScript
+----------
+
+* Use CoffeeScript.
+
+CSS
+---
+
+* Use Sass.
+
Browsers
--------
10 protocol/README.md
View
@@ -69,6 +69,16 @@ Use [Foreman](http://goo.gl/oy4uw) to run the app locally.
It uses your `.env` file and `Procfile` to run processes just like Heroku's
[Cedar](https://devcenter.heroku.com/articles/cedar/) stack.
+Maintain a Rails app
+--------------------
+
+* Avoid including files in source control that are specific to your
+ development machine or process.
+* Delete local and remote feature branches after merging.
+* Perform work in a feature branch.
+* Rebase frequently to incorporate upstream changes.
+* Use a [pull request](http://goo.gl/Kmdee) for code reviews.
+
Write a feature
---------------
28 style/README.md
View
@@ -6,13 +6,7 @@ A guide for programming in style.
Git
---
-* Avoid including files in source control that are specific to your
- development machine or process.
-* Delete local and remote feature branches after merging.
-* Perform work in a feature branch.
* Prefix feature branch names with your initials.
-* Rebase frequently to incorporate upstream changes.
-* Use a [pull request](http://goo.gl/Kmdee) for code reviews.
* Write a [good commit message](http://goo.gl/w11us).
Formatting
@@ -60,11 +54,6 @@ Organization
* Order methods so that methods are as close as possible to other methods they
call.
-CSS
----
-
-* Use Sass.
-
Sass
----
@@ -75,11 +64,6 @@ Sass
* Order properties within rule sets alphabetically.
* Leave a blank line between rule sets.
-JavaScript
-----------
-
-* Use CoffeeScript.
-
CoffeeScript
------------
@@ -131,12 +115,7 @@ Rails
* Avoid `member` and `collection` routes.
* Avoid the `:except` option in routes.
-* Don't reference a model class directly from a view.
* Don't use protected controller methods.
-* Don't use SQL or SQL fragments (`where('inviter_id IS NOT NULL')`) outside
- of models.
-* Keep the `db/schema.rb` under version control.
-* If there are default values, set them in migrations.
* Name date columns with `_on` suffixes.
* Name datetime columns with `_at` suffixes.
* Name initializers for their gem name.
@@ -147,9 +126,7 @@ Rails
* Order resourceful routes alphabetically by name.
* Put application-wide partials in the
[`app/views/application`](http://goo.gl/5Z8Vv) directory.
-* Use `_path`, not `_url`, for named routes everywhere except mailer views.
* Use `def self.method`, not the `scope :method` DSL.
-* Use SQL, not `ActiveRecord` models, in migrations.
* Use the default `render 'partial'` syntax over `render partial: 'partial'`.
* Use the `:only` option to explicitly state exposed routes.
@@ -172,8 +149,6 @@ Testing
[Sample](samples/testing.rb)
-* Avoid `its`, `let`, `let!`, `specify`, `before`, and `subject`.
-* Avoid using instance variables in tests.
* Avoid scenario titles that add no information, such as "successfully."
* Avoid scenario titles that repeat the feature title.
* Avoid the `private` keyword in specs.
@@ -191,10 +166,7 @@ Testing
module.
* Prefer `eq` to `==` in RSpec.
* Separate setup, exercise, verification, and teardown phases with newlines.
-* Use an `it` example for each execution path through the method.
* Use one factories.rb file per project.
-* Use [stubs and spies](http://goo.gl/EciDJ) (not mocks) in isolated tests.
-* Use a single level of abstraction within scenarios.
* Use names like `ROLE_ACTION_spec.rb`, such as
`user_changes_password_spec.rb`, for feature spec file names.
* Use only one `feature` block per feature spec file.
Orban Botond

Hi @jferris,

May I ask why 'let' is harmfull in RSpec?

Joshua Clayton

@orbanbotond We've written a blog post which outlines why we avoid most of these here: http://robots.thoughtbot.com/lets-not

Please sign in to comment.
Something went wrong with that request. Please try again.