Hound: A service that comments on Ruby style violations in GitHub pull requests(robots.thoughtbot.com) |
Hound: A service that comments on Ruby style violations in GitHub pull requests(robots.thoughtbot.com) |
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.
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.
As long as you decide on a number, you want to pick something that is wide enough to be useful, but small enough that it doesn't lend itself to abuse (overly long variable names, 8 levels of indentation, and so on).
Also, it's nice to be able to look at two or three columns of code in a reasonable font size on your monitor, to view it in websites of normal width, and so on. And to know that you can still view code just fine on your 11" Macbook Air, even with a project-tree sidebar open in your editor.
For legibility, typeset columns are often recommended to contain something around 60 characters per line, although there's clearly a range. [1] Because code is often indented 1-4 levels (unlike normal text), it makes sense to expand this somewhat, and 80 is a nice round number for this.
So, 80 is probably the most common number I've seen for code line length, and there's absolutely nothing cargo-cult about it. It's simply that, if you don't want to implement line-wrapping, you need to pick something, and 80 is quite reasonable.
1: My 15" screen is about 160 characters at my preferred font size. When I want split screen to compare two files then each one should only be about 80 characters. There is even less space when using IDEs or text editors that include file drawers or other widgets.
2: Excessive characters on one line is a code smell just like excessive line counts in one method. You agree that 300 characters is too much. If 90 is too little then at what point should an automated tool trigger a warning?
All the good practices about programming will mention that:
1) Excessive line count in a method is a code smell 2) Excessive number of characters is also a code smell 3) Non descriptive variable names are universally considered bad practice.
Now my problem with all this dogma is that if you combine 1, 2 and 3, you're left with a severe conundrum. And to me, excessive number of lines in a method and naming your variables a,b,c,d,e are concessions that I prefer to avoid if I can simply crank up the number of characters on a line (taking into account indentation caused by conditionals, method definitions, blocks, etc).
I'm with you, though. 80 characters is really short, especially if you are indented more than a few stops. It also discourages descriptive variable/method names, which harms readability of code far more than slightly longer lines.
I exclude the tab/spaces debate from this because it has ramifications outside of mere stylistic concerns.
set nowrapI definitely pass 80 characters when it makes sense, and I use the appropriate pragmas to make rubocop understand not to warn me. But for the most part, 80 characters as a limit helps me know when my lines are getting to long.
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.)
https://houndci.com/configuration
> the change is a false positive
I've been using Hound on about a dozen projects the last few months and haven't seen false positives. We built it atop Rubocop, which has been pretty well-vetted.
> Software development has too many unwritten rules and social interactions for a bot
We've limited our guidelines to a subset that should almost always be "no argument, my bad, fixed in [SHA hash]." However, it comments instead of failing the build or mechanically changing the code because that the human should make the final decision about whether to make the change.
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.
Almost all of the tools are very configurable in terms of which warnings/errors you want to ignore (e.g., let our max line length be 120 instead of 80), and give pretty good feedback (line numbers, exact error).
Another great benefit is that you have a neutral arbiter of what's the style for your codebase, which helps avoid ruffled feathers.
I'm hoping to create a git filter that stops the commit from happening if there are style guide violations.
You should be able to do this using a pre-commit hook.
We've tried putting style violations in the build and found there are enough edge cases that it isn't exactly the interaction we've wanted. Sometimes, we want the human to say "no, my pair and I broke the guideline on purpose and we're okay with it in this case." We don't want a broken build in those cases.
Totally agree with you about getting feedback earlier than opening a PR, though. Linters integrated into text editors are a great way to go.
Rubocop can even correct some style errors automatically now!
> It places the focus value not on our super-secret-source-code but on our handling of the hosting, billing, and maintenance of that source code.
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.
First you fix (3), by naming variables in a nice, descriptive way - that possibly causes violations of (2).
Then you fix (2), by having lines/statements that are clear and don't do ten things at once - that possibly causes violations of (1).
And then, you fix (1), by refactoring your methods properly - and that is a valid goal by itself.
If instead you have longer lines, then the problem of your method being too big doesn't go away, it still does the same thing, you just don't notice it. If (1)+(2)+(3) would force you to split up your methods, then that's an indication that those methods should be split up anyway, even if you choose to ignore (2) and (3) - "too many lines of code" is a code smell simply because it correlates to "does too much", and even a one-line method can possibly be doing too much, if it's written in code-golf-style.
https://www.dropbox.com/s/txlzh5jzrt30afs/Screenshot%202014-...
Again, we have reissued our certificates and installed them since the servers were patched.
"We intend to charge in the near future to ensure Hound is sustainable, but public projects will continue to be free."
1. Scroll off the side of the window
Pain in the ass. Ever try diffing a file, and had to scroll?
2. Wrap
Also a pain in the ass. Formatting alignment, confusion over where important linebreaks are, etc.
Many editors don’t fully support soft wrapping, sadly. But if you’re lucky enough to use an editor that includes the necessary features, there are no problems with soft wrapping. Soft wrapping has the advantage that you never have to manually re-wrap a line. These editor features make soft wrapping useable:
Display noneditable symbols at wrap points to mark them as nonimportant linebreaks. In Vim, `set showbreak=->` to display “->” at wrapped lines. Emacs supports putting arrow symbols in the “fringe”. Visual Studio has a preference to enable this.
Indent wrapped lines at the same indentation as the start of the line, optionally plus extra indentation. Vim does not support this but there is a patch for Vim that makes this enable-able with `set breakindent`. Coda supports it fully, with customizable extra indentation. This is the least-supported, most-important feature of making wrapping useable.
Separate logical-line movement and visual-line movement. Pretty much every editor supports this. Logical-line movement is really only necessary in macros, anyway. In Vim, it’s j/k (or -/<Enter>) vs gj/gk. In Sublime Text, it’s up/down vs option-up/option-down (or some combination like that).
They definitely help. I just find it inconvenient to need to scroll, and sometimes arrows don't fit my usage case..
Not the editor's fault in either instance, of course. :-)
