Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save suweller/b896eb9e66fc6ab3640d to your computer and use it in GitHub Desktop.
Save suweller/b896eb9e66fc6ab3640d to your computer and use it in GitHub Desktop.
80beans Github Emoji etiquette

Styleguide

We follow the ruby style guide, with some minor additions:

Basics

  • No trailing whitespace
  • Text files end with EOL EOF (git diff | grep 'No newline at end of file' should come up blank)

Private projects

On private projects we allow lines to be 114 characters long, instead of the 80 allowed by ruby style guide. This is just enough to have all lines fit nicely in a GitHub pull request file changes window.

Public / Open-Source projects

For public projects, we stick with 80 characters per line, in memory of good ol' punch cards.

Classes

DSL calls (ruby, rails, rspec), and CONSTANTS are allowed to be placed against the class definition, while other code is not.

All ends should be preceeded by a newline.

Good:

class SomeClass
  include OtherClass

end

class SomeClass
  attr_reader :foo

end

class SomeClass

  def initialize
  end

end

Bad:

class SomeClass

  include OtherClass

end

class SomeClass

  attr_reader :foo

end

class SomeClass
  def initialize
  end

end

The same holds for defining class methods like this:

class SomeClass
  class << self

    def class_method
    end

  end

end

Both whitelines need to be present. The first to signify the end of the class method definition, the second to signify ending the class definition.

Methods

Instead of using double indent or normal indent, we prefer:

def send_mail(source)
  Mailer.deliver(
    to: 'bob@example.com',
    from: 'us@example.com',
    subject: 'Important message',
    body: source.text
  )
end

Specs

Good:

describe 'foo' do
  let(:variable) { ... }                # setup block
  subject { ... }                       #
  before { ... }                        #

  it { should be_a Hashr }              # inline tests block
  its(:foo) { should == :bar }          #
  its(:bar) { should == :baz }          #

  it "marks the end" do                 # test block
    # ...                               #
  end                                   #

  after { ... }                         # after hooks
end
  • Setup blocks have a single empty line, at its end.
  • After hooks are placed at the very end of the parent block.
  • inline it or its don't have an empty line separating them.
  • end of the block don't have an empty line separating them.

Good:

describe 'foo' do
  context 'bar' do
    let(:variable) { ... }              # setup block
    subject { ... }                     #

    it { should be_a Hashr }            # inline test block
  end

  describe 'bar' do
    let(:variable) { ... }              # setup block
    subject { ... }                     #

    it { should be_nil }                # inline test block
  end
end
  • Without a setup block, the next block leans against the parent block.
  • within every describe or context block, the same rules apply

Acceptance specs

Acceptance specs use the same rules, with the addition of adding an empty line whenever we change from an action to an assertion block, or vice versa.

Good:

feature 'some feature' do
  background do                         # setup block
    # ...                               #
  end                                   #

  scenario 'some thing it does' do
    check 'foo'                         # action block
    select 'bar'                        #
    click_button 'submit'               #

    page.should have_content 'a-ok'     # assertion block
    page.should have_content 'foobar'   #
  end
end

Whitespace fish

fish

The ultimate humiliation. Given for not adhering to the 80beans whitespace guidelines.

Emoji cop

cop

For using the wrong Emoij

Excellent patch rainbow

rainbow

Flawless/Awesome/Pain-Obliterating code

Note: The rainbow can never, under any circumstances be awarded after getting a negative Emoji. Your patch has to be flawless. For truly exceptionally great code, the rainbow can be doubled.

Git commit Octocat

octocat

Bad/Long/Past-tense commit messages

Merge conflict monkey

monkey

For committing (part-of) a merge conflict. Uber humiliation, fishes are a far cry receiving a monkey

Monorail coding

monorail

For the line that goes on and on; Next stop, EOF! Any line longer than 115 characters is a suitable candidate for the monorail.

Quote fail dog

dog

Forgetting to double quote strings in yaml files or in spec describe, context, and it blocks.

Test coverage koala

koala

Writing code lacking test coverage.

Undescriptive name bear

bear

Using undescriptive names in any part of your code.

Not translated (:underage:)

underage

Text is not translated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment