Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jan 22, 2015
  1. @penge @jferris

    Use double colons for pseudo-elements

    penge authored jferris committed
Commits on Jan 16, 2015
  1. @JoelQ

    Remove RSpec guideline for one-liners

    JoelQ authored
    Previously one-liners could be written in RSpec like:
        it { should validate_presence_of(:name) }
    In RSpec 3, the `should` syntax was removed because it monkey-patched `Object`.
    The one-liner syntax shown above was kept because its `should` did not
    monkey-patch `Object`. To avoid confusion, RSpec 3 added an `expect`-style way
    of writing one-liners:
        it { validate_presence_of(:name) }
    According to Myron Marston:
    > Some users have expressed confusion about how this should relates to the
    > expect syntax and if you can continue using it. It will continue to be
    > available in RSpec 3 (again, regardless of your syntax configuration), but
    > we’ve also added an alternate API that is a bit more consistent with the
    > expect syntax
    From: [New API for
    A proposal was made to switch to using the new `` syntaxin [this
    pull request](#215). However, responses
    were mixed. Given the lack of consensus one way or the other, let's remove the
    guideline entirely and let each project decide which syntax to use.
  2. Merge branch 'sd-fix-typo'

    Steve Dixon authored
Commits on Jan 15, 2015
  1. @keith

    Update Objective-C examples

    keith authored
  2. @creuter

    Sass: Prefer mixins to @extends

    creuter authored
    Extends can cause long, unwieldy selectors if not minded. Compiled file
    size is negligible with Gzip. Extending doesn't work across media
    queries, and can't gracefully accept arguments.
    Further discussion at thoughtbot/bitters#140
  3. @mike-burns

    A pull system means never assigning

    mike-burns authored
    This introduces a new communications section for describing how best to
    communicate like a thoughtbotter.
    Up first: tickets. We use Trello right now, but the principles of how we
    use it are the same as when we used Pivotal Tracker, JIRA, Trajectory,
    GitHub Issues, and everything else. Therefore I've left it as just
    We follow a pull system, which means:
    * For client projects, the next designer or developer takes the ticket
      with top priority.
    * For discussion topics, such as happens on the Research board, people
      subscribe to tickets they are interested in.
    We use a modified Kanban/CONWIP at thoughtbot. This commit message is
    not the place to go into the full details of why we chose to do that,
    but at its simplest the output is controlled by demand (e.g. "the
    user wants this" or "the blog post author wants to write this") and
    not by forecast ("this is due on Thursday", or by analogy "I want you to
    write this"). This reflects how we believe software can be built and
    how to run a sustainable, happy workplace.
Commits on Jan 14, 2015
  1. @keith
  2. @keith

    Remove outdated swift example

    keith authored
    Show example case
  3. @geoffharcourt @jferris

    Add convention for time without date columns

    geoffharcourt authored jferris committed
    Rails returns times without dates from the database as `Time` objects (as a time
    on the date `2000-01-01` in UTC), which can lead to confusion with actual
    datetimes. Although we can't make the returned value clearer, uniformly naming
    these columns with the suffix `_time` can at least remove confusion while
    reading the code.
  4. @jferris

    Prefer scroll to auto for overflow

    jferris authored
    * `overflow: auto` uses scrollbars only when the content doesn't fit
    * `overflow: scroll` always uses scrollbars except on OS X
  5. @JoelQ

    Break up style guide by language/framework

    JoelQ authored
    Our Styles guideline has grown large and cumbersome. It is over 400
    lines long and has 22 sections (some of which have several subsections.
    The directory structure looks like this:
        └── samples
            ├── ObjectiveC.m
            ├── Swift.swift
            ├── acceptance_test.rb
            ├── android_layout.xml
            ├── erb.rb
            ├── haskell.hs
            ├── migration.rb
            ├── predicate_tests.rb
            ├── ruby.rb
            ├── sass.scss
            └── testing.rb
    In this commit, I've left some of the general section in the main README
    and broken out all of the language/framework-specific stuff into
    subdirectories, each with their own README and examples. The directory
    structure now looks like:
        ├── android
        │   ├──
        │   └── android_layout.xml
        ├── backbone
        │   ├──
        │   └──
        ├── coffeescript
        │   ├──
        │   └──
        ├── ember
        │   └──
        ├── erb
        │   ├──
        │   └── sample.html.erb
        ├── git
        │   └──
        ├── haskell
        │   ├──
        │   └── sample.hs
        ├── html
        │   └──
        ├── objective_c
        │   ├──
        │   └── sample.m
        ├── python
        │   └──
        ├── rails
        │   ├──
        │   └── migration.rb
        ├── ruby
        │   ├──
        │   └── sample.rb
        ├── sass
        │   ├──
        │   └── sample.scss
        ├── shell
        │   └──
        ├── swift
        │   ├──
        │   └── sample.swift
        └── testing
            ├── acceptance_test_spec.rb
            ├── predicate_tests_spec.rb
            └── unit_test_spec.rb
    This should make it easier to look up the relevant style guide as well
    as make it simpler to deal with multiple, smaller sample files for each
    language. This organization pattern would also support
    #261 very well.
    This commit simply changes the directory structure and breaks out
    sections of the style guide. Other refactorings that could build on this
    * Break up long lists of bullet points under several headings
    * Break up large example files into smaller more focused example files
Commits on Jan 13, 2015
  1. @graysonwright

    Define custom subjects as needed for one-liners

    graysonwright authored
    - Move custom subjects guideline to a best practice
    - Add `subject` examples to `style/samples/testing.rb`
    - Clarify when it's *not* okay to use `subject`
Commits on Jan 8, 2015
  1. @mike-burns

    Decide when to merge your branch

    mike-burns authored
    The value of a code review is in the feedback from other developers.
    Once the developer gets feedback, it's up to hir to decide whether the
    branch is ready to merge.
    Sign-off is handy for some repos which affect everyone (guides,
    playbook, handbook, etc.). Others, such as the blog or code, can be more
    lax. As such, simplify the suggestion in the guide and empower the
    merger to take power.
Commits on Jan 5, 2015
  1. @croaky
Commits on Dec 22, 2014
  1. @drapergeek

    Ensure that links and buttons are used.

    drapergeek authored
    * Without the href= in an anchor tag, the hover effect does not work.
Commits on Dec 20, 2014
  1. @keith
Commits on Dec 19, 2014
  1. @mntj @mxie

    Remove typo from long variable name in ruby.rb

    mntj authored mxie committed
Commits on Dec 16, 2014
  1. @mike-burns

    Only follow a best practice if you understand it

    mike-burns authored
    The styles should always be followed, and anything that is a style
    guideline should be defensible with just "we picked this style."
    The best practices are things that we've learned through experience and
    teaching, and therefore cannot be conveyed completely in a pithy
    guideline. They are reminders for those who understand them, not lessons
    for those looking to learn.
    As such, if you do not understand a best practice guideline, then you
    are simply not the target audience.
Commits on Dec 10, 2014
  1. @keith
  2. Fix typo.

    Steve Dixon authored
Commits on Nov 20, 2014
  1. @derekprior

    Prefer `reduce` over `inject`

    derekprior authored
    `reduce` provides symmetry with our already-preferred `map`.
    Additionally, it has a more intention-revealing name and is more
    approachable for people unfamiliar with it. "I am reducing this array to
    something". `inject` doesn't make the same sense.
Commits on Nov 19, 2014
  1. @derekprior

    Add Angular Best Practices

    derekprior authored
    A first crack at some Angular best practices arrived at through a seven
    month angular project and discussions with other teams doing angular
    work around the company. I'm no angular expert, but these are practices
    I can remember working well, particularly in the face of other options
    that *did not* work equally well.
Commits on Nov 10, 2014
  1. @gabebw

    Use `ENV.fetch` instead of `ENV[]`

    gabebw authored
    It's easy to forget to set environment variables (e.g. `AWS_SECRET_KEY`) on
    staging or production. Using `ENV.fetch("AWS_SECRET_KEY")` ensures that missing
    environment variables raise errors instead of just being `nil`.
    Heroku boots the app on deploy, which runs the app's initializers. Often,
    environment variables are set in an initializer. This combination means that if
    an environment variable isn't set, an error will be raised and Heroku will abort
    the deploy. This means users can never see a version of the app without the environment
    variables set.
Commits on Nov 7, 2014
  1. @drapergeek
Commits on Nov 6, 2014
  1. @drapergeek
Commits on Nov 4, 2014
  1. @pbrisbin

    Rewrite `printf` vs `echo` guideline

    pbrisbin authored
    If not passing options, including escapes, or including variables (which
    may contain escapes), `echo` will work consistently across systems. It
    should not be broadly avoided as this simple and safe use-case is
Commits on Oct 19, 2014
  1. @croaky

    Add "Product Review" protocol before "Code Review"

    croaky authored
    Our core workflow has been:
    * Work in feature branch.
    * Open GitHub pull request for code review.
    * Make changes based on teammate feedback.
    * Merge into master.
    * Push to staging.
    * Get feedback on the product in-browser from teammates.
    This generally works well.
    However, when something isn't quite right with the product
    and the developer needs to make changes,
    the feedback loop is too slow.
    Fast-moving startup teams may want to blame code reviews for causing problems.
    However, fewer or sloppier reviews lead to
    problems like bugs and hard-to-change code.
    We still highly value code reviews.
    Our hypothesis is that the root problem is that the steps are out of order.
    What if we performed "Product Review" before "Code Review"?
    ![Product before Code](
    Moving "Product Review" before "Code Review" in our core workflow
    can be solved in different ways.
    The most effective is when [teammates are available in person.
    However, that's not always feasible.
    Many teams value remote work due to teammates' choices of
    where they want to live and when they want to work.
    In the absence of *always* having teammates
    who are *always* available in person,
    we have [experimented with approaches] for about 18 months.
    [experimented with approaches]:
    This pull request captures the conclusions of the successful experiments.
Commits on Oct 9, 2014
  1. @penge @jferris

    Add missing links to samples

    penge authored jferris committed
Commits on Oct 8, 2014
  1. @sgrif

    Add style guide for order of properties in Android views

    sgrif authored
    Alphabetized is pretty much the standard, but we felt that `id`,
    `layout_width`, and `layout_height` should be listed first. `id` is
    the property you care about most (if it is present), and should be
    quick to find at a glance. `layout_width` and `layout_height` are
    required on all views, and affect the layout of the view most, so they
    should also be separated from the rest.
Commits on Sep 19, 2014
  1. @gylaz

    Reword per suggestion

    gylaz authored
Commits on Sep 18, 2014
  1. @gylaz
Commits on Sep 16, 2014
  1. @tonyd256
Commits on Sep 14, 2014
  1. @ugisozols

    Remove extra : from link.

    ugisozols authored
Commits on Sep 11, 2014
  1. @croaky

    Add CoffeeScript colon assignment spaces guideline

    croaky authored
    This can be enforced in Hound with the `colon_assignment_spacing` option in
Commits on Sep 5, 2014
  1. @croaky

    Avoid backticks in CoffeeScript

    croaky authored
    Backticks allow snippets of JavaScript to be embedded in CoffeeScript. While
    some folks consider backticks useful in a few niche circumstances, they should
    be avoided because so none of JavaScript's "bad parts", like <tt>with</tt> and
    <tt>eval</tt>, sneak into CoffeeScript.
    This can be enforced by Hound with the `no_backticks` option in CoffeeLint,
    which is enabled by default.
    This is an "Avoid", not a "Don't", because in `ember-cli` the import statements
    do not work in CoffeeScript and we have to use the backticks:
    There are some cases where it is unavoidable.
    Also: alphabetize the CoffeeScript guidelines.
Something went wrong with that request. Please try again.