In our style guide:

Prefer detect over find.

But hound is commenting with:

Prefer find over detect.

The guides say to put the . at the end of the line: thoughtbot/guides@237d16b

But @houndci wanted them at the beginning of the next line: thoughtbot/gitsh#149 (see the comments on the outdated diffs).

I would like to be able to run RuboCop against my project with the same configuration as Hound. Please provide a full RuboCop config that matches the config of Hound.

According to the configuration of hound:

By default, Hound uses THOUGHTBOT'S STYLE GUIDE with no additional setup.

Custom configuration of the style guide is entirely optional and is achieved by specifying rules in .hound.yml file.

Hound uses RUBOCOP gem to handle the style checking. Thus, most of the RuboCop configuration, except inheritance, is supported in Hound as well.

Hound will look for .hound.yml file in the root of the repo, and apply the custom configuration on top of the default configuration.

I know hound doesn't use the default rubocop styles but thoughtbot's styles. However, I can't find that default configuration file. I would like to know what it is, so that it is easier for me to understand where your styleguide and mine differ.

Can you point me to where the config exists? I can't seem to find it in source.

I recently got these comments from Hound:

Avoid comma after the last parameter of a method call.

Avoid comma after the last item of a hash.

This isn't mentioned in the thoughtbot style guide.

We have delimiters in a spec and hound is complaining but we can't use do & end.

  it {
    should delegate_method(:default_variant_name).
      to(:default_variant).
      as(:name)
  }

Avoid using {...} for multi-line blocks.

I think this behaviour is not what we want in cases like the one above.

Currently @houndci will join the first team that the enabled repository is a part of. I don't think this is necessary and I strongly believe that it is a much better approach if @houndci would create the "Services" team and join it at all times. (I mean why bother? Especially when there are multiple teams, it gets tricky.)

By the way, what happens if there is already team named "Services"?

Thank you,

This isn't in our guides, but Hound complains about it: https://github.com/thoughtbot/guides/search?q=before_action&ref=cmdform

There is a problem when in pull request have file which is bigger than 1 MB file.
Then Resque is failing and all other comments on Pull Request are skipping too..

Error

Octokit::Forbidden

Error
GET: 403 - This API returns blobs up to 1 MB in size.The requested blob is
too large to fetch via the API, but you can use the Git Data API to request blobs
up to 100 MB in size. Error summary: resource: Blob field: data code: too_large
// See: https://developer.github.com/v3/repos/contents/#get-contents

Solution

We can rescue that error to skip those big files and keep checking other files.

path/to/project/lib/github_api.rb:75:in `file_contents'
path/to/project/app/models/pull_request.rb:62:in `file_contents'
path/to/project/app/models/pull_request.rb:58:in `build_commit_file'
path/to/project/app/models/pull_request.rb:19:in `block in pull_request_files'
path/to/project/app/models/pull_request.rb:18:in `map'
path/to/project/app/models/pull_request.rb:18:in `pull_request_files'

Hi guys, I had similar idea and I'm very happy you made it.
I was planning to make it a full featured service like :

Keep the full history on the website, browse the files, statistics, badges, scores ...
Github comments was an option you can switch on/off.

Do you have similar vision for the future of the project or you just want to stick with Github comments?

I am interested in contributing ;)

https://github.com/thoughtbot/gusher/pull/4#discussion-diff-10887908

The reported issue isn't in the highlighted diff. It's actually on the line below the one where the diff ended.

Hound reported that a "space missing after colon" when working with a Ruby 2.1 required named argument.

For example:

def fill_in_coupon_form(attributes, course_name:, value:, type:)

Hound wanted

def fill_in_coupon_form(attributes, course_name: , value:, type:)

Is this violation intended? It seems like it makes sense for Ruby 1.9 hash syntax but doesn't seem to apply here for named arguments. Not sure if theres a way to even differentiate between the 2 though.

Hi,

I find that hound can't see my repos that are within an organization. I've tried to enable all scopes of the oauth token used by the hound user but it still can't find them. Do I must be the owner of the repos for hound to find them?

Any help would be appreciated!
Thanks

There isn't anything in our style guide about this, but Hound is leaving these comments:

Rename has_solutions_by_other_users? to solutions_by_other_users?.

This is annoying, because renaming as suggested would break RSpec predicate matchers like expect(review).to have_solutions_by_other_users.

https://github.com/thoughtbot/oneblock/pull/38#discussion_r12610426

Getting a hound notification that I should align my parameters, but doing so causes a syntax error.

thoughtbot/suspenders#297 (comment)

Hound is adding line comments not based on additional changes but on the entire diff, even if the line already had a comment and was unchanged in the update.

I couldn't find anything in #257 that looked like it would resolve this, but I might have missed something.

Hound did not comment on my single line if statement and I believe that is a violation of the ruby style guide

number if factors.any? { |multiple| number % multiple == 0 }

mrageh/exercism#2

https://github.com/thoughtbot/suspenders/pull/301/files#r10698987

This is within the method, and being detected both after an if / end and a multiline method call.

Which, incidentally, it didn't call out for being multiline without parens.

If I run Rubocop on the CL, things are evaluated as expected, but Hound continues to yell at many of my PR's.

The parts of my .hound.yml of interest:

AllCops:
  RunRailsCops: true
  Exclude:
    - 'bin/**/*'
    - 'config/environments/**/*'
    - 'config/initializers/devise.rb'
    - 'db/**/*'
    - 'vendor/**/*'

IndentationConsistency:
  Exclude:
    - '**/factories/**/*'

IndentationWidth:
  Exclude:
    - '**/factories/**/*'

RedundantSelf:
  Exclude:
    - '**/models/**/*'

thoughtbot/griddler#119

If violation happens multiple times on the same line, then Hound will print out the violation message multiple times.

Probably makes the most sense to display the message once.

There have been a number of cases now of Rubocop enforcing styles which are not part of our style guide. If possible, I think it makes sense to have everything off by default and then enable things which we know match our style guide.

This seems to be a consistent pattern:

• one person on the team adds houndci to a project
• PRs get a bunch of notifications about line length and block spacing that some people disagree with
• said people can't immediately figure out how to edit .hound.yml to disable those validations
• said people get frustrated and remove houndci entirely

It would be nice if hound comments (optionally) started with the yml keys of the relevant rubocop rules (e.g. LineLength: Limit lines to 80 characters.) or could be linked to them in some convenient way. That would make it easier for developers to determine which options to add (or omit) from the yml file.

This suggestion is entirely pragmatic; I don't think the frustration I've seen with hound is really warranted, but I think you will have more users and do more good in the world if disabling hound messages for particular style violations is easier/more intuitive.

 class PullRequest
-  CONFIG_FILE = '.hound.yml'
+  CONFIG_FILES = ['.hound.yml', '.rubocop.yml']

etc

I'm not sure why we need to get write access to repositories and orgs, or to notifications.

Commit status makes perfect sense.

the following triggers an incorrect warning:

private def foo
  bar
end

It says that bar should be indented 2 spaces, not -6 (minus six). It seems to count starting from def, but it should start from the start of the statement.

An exception for 'private' wouldn't be enough. For instance:

before_filter def foo
  bar
end

Are there any near-term plans for BitBucket support?

https://github.com/thoughtbot/whetstone/pull/32/files#r10799668

The line is 71 characters long, but Hound is complaining that it's 82. Maybe a race condition between Hound being triggered and Harry pushing to the branch again?

I got this message on the following line:

class Admin::LocationsController < ApplicationController

I can't find this rule in the style guide, so we should either add it to the guide or disable the check in hound.

While it may be implicit since you're leveraging RuboCop, you should make it obvious on houndci.com (and/or in the readme) that you can edit any of the style guide rules and that you're not limited to ThoughtBot's style guide (eg https://gist.github.com/salbertson/d5eb2d42f68df9e18d10).

This seems like a reasonable next step, as an opt-in sort of thing. http://developer.github.com/v3/pulls/comments/#create-a-comment

We should either turn off this check in hound, or add this to our style guide.

There's no mention in the style guide of %r literals. We should turn off this check in hound, or add it to the style guide.

With a fresh install I'm getting a local failing test.

Failures:

  1) Repo list user signs up
     Failure/Error: expect(page).to have_content I18n.t('syncing_repos').upcase
       expected to find text "LOADING REPOS..." in "HOUNDREPOS GITHUB17 ACTIVE REPOS: OF REFRESH REPO LIST"
     # ./spec/features/repo_list_spec.rb:53:in `block (3 levels) in <top (required)>'
     # ./spec/features/repo_list_spec.rb:129:in `with_job_delay'
     # ./spec/features/repo_list_spec.rb:48:in `block (2 levels) in <top (required)>'

Finished in 8.64 seconds
188 examples, 1 failure, 9 pending

You can see an example of this here, i've pushed three times:

I don't find this in our style guide anywhere, so I'm not sure how this crept in there.

We're in a situation now where adding a new style guideline means:

1. Opening a pull request to guides.
2. Waiting a week for discussion.
3. Merging the pull request.
4. Opening a pull request to hound.
5. Reviewing, merging, and deploying that pull request.

In between steps 3 and 5, we get comments from Hound which conflict with our style guide.

It would be nice if:

• We had a config file in the guides repo.
• We could point Hound to it as our default config.
• Hound would somehow fetch updates for that config.

This way, we could update the config as part of pull requests which change the style guidelines. The guides and Hound will never be out of sync.

We are using an older version of ruby and noticed that when we changed the .hound.yml file to:

Style/HashSyntax:
  EnforcedStyle: hash_rockets

It still was using the ruby19 supported style. What gives?

Is there support for bitbucket planned?

They have a rest-api like github, documented here: https://confluence.atlassian.com/x/IYBGDQ.

Guys what about gitlab support?
I see here and there that github api is hardcoded, do you plan/have any thoughts on this one?

There is https://github.com/NARKOZ/gitlab that can be used for interacting with gitlab.

Great job btw

I've seen the following message a few times, related to method calls that were wrapped like this:

some_method(foo: {
  bar: 1, # Hound comments on this line
  baz: 2,
})

It looks like rubocop wants this:

some_method(foo: {
              bar: 1,
              baz: 2,
            })

This seems to go against a couple of guidelines:

• Don't vertically align tokens on consecutive lines.
• Indent continued lines two spaces.

This was brought up by @hstove in #201.

Can Hound be configured to review GitHub commit pushes instead of pull requests?

I see a pull request for coffee-lint. Would you guys be interested in other languages such as PHP? I had an idea to do this for PHP and created a little demo app that is working for a private repo, but this repo is much more extensive and well rounded I'd much rather enable it here then start my own repo or have a diverged fork. Lemme know what you guys think!

This is actually the opposite of what we have in the style guide:

Avoid explicit return statements.

Hound is complaining:

Use delegate to define delegations.

But this is not part of our style guide.

This could just be me, but I think we should ignore style checking params globally. There are several api's that use camelCase instead of snake case and its weird we are validating styles for incoming parameters.

I can see an argument being made for both sides but its a layer of polish imo.