Can someone shed some light on the reason why we're still bothering with "line is too long" in 2014?<p>I mean I'm not talking 300 characters-long lines here that's ridiculous, but the idea that a line with 90 characters is "too long" because some arbitrary limit in the width of certain terminal emulators back in the days was fixed at whatever number of columns seems really backwards.<p>So yeah, I'm open too any sane explanation of the why that is actually good practice beyond what I perceive as severe cargo culting.
I have always liked the idea of these bots roaming github, looking for bugs to fix and code that could be improved. But, it almost always ends up annoying somehow. Either the change is a false positive, the bot doesn't understand the project structure, or the bot just spams changes. Software development has too many unwritten rules and social interactions for a bot to just send PRs and comments.<p>Perhaps another type of communication, other than issues, PRs, and comments, is needed just for bots. I would tolerate my projects being scanned, if I could separate the human and bot communication streams. (And, block bots when they don't work as expected.)
I love this. On just about any team I have worked on, whenever a fresh PR comes in everyone goes through it picking out style guide violations. It's tedious, annoying and sometimes arbitrary if the team doesn't have a solid style guide in place. Hound will let us get right to reviewing what matters: the code itself.<p>Up next: I would love a Unix utility I could filter my uncommitted diff through and get style guide violations before I even upload to GitHub. Use git for everything, baby.
<a href="https://github.com/bbatsov/rubocop" rel="nofollow">https://github.com/bbatsov/rubocop</a> FTW. Integrate it into your test suite and you can see your mistakes before you push up a change for your team to see.
Take a look at <a href="https://github.com/mmozuras/pronto" rel="nofollow">https://github.com/mmozuras/pronto</a> - does the same, has many adapters.
One thing I've liked with hound is that when it comes up with what I'd consider a "false positive," such as a line with a url that can't be split, I can just reply inline to explain why that couldn't change. This pull has a lot of examples of that: <a href="https://github.com/thoughtbot/griddler/pull/119" rel="nofollow">https://github.com/thoughtbot/griddler/pull/119</a>
The marketing site needs some work. There's no details about pricing that I can find and no information about configuring your own rules (I had to read the source code to see if that was possible). I am not going to sign up with GitHub to see either of those things, they need to be public.
This is really cool. Sure, similar tools have existed for a while, but Hound looks far simpler to setup and use than previous tools.<p>However, it would be nice to have this optionally run on every commit rather than only on pull requests. For my own personal projects, I obviously don't submit pull requests to myself, but I would like to have Hound double-check my code for me.
This is great. Is it possible to use this as a rake task? I think it would be better to have team members run this locally just like they would run a test suite, make sure everything is up to par, and then open a PR. This would keep the communication stream in the PR nice and clean, focused only on code implementation.
This is a great product. I was working on a product when a new developer joined and started writing Ruby like he was writing in PHP, ignoring all of the programming language's idioms. What was worse was that with every commit where his code was "cleaned up", he'd put them back in!
Not sure I'd want to give this site Github access:
<a href="http://filippo.io/Heartbleed/#houndci.com" rel="nofollow">http://filippo.io/Heartbleed/#houndci.com</a>