Code search turned code checker

[rvantonder]

---

Notes to self:

Before publishing:

• page visit should trigger Search console: trigger search on page load sourcegraph#14437
• encodeURIComponent search: encode ampersand in search console sourcegraph#14394
• clicking back should restore previous history Hide 'show more' on search console page sourcegraph#14478
• deny count:1000 page visit should trigger Hide 'show more' on search console page sourcegraph#14478
• index all repos in go-gh-100
• Two bugs:

if strings.HasPrefix(:[str.], :[prefix.]) {
  :[str.] = :[str.][len(:[prefix]):]
} :[~else]

doesn't work

and

simple select

---

Nice to haves:

• Layout improvement (maybe 5/12 editor, 7/12 results)
• comments in editor search: add C-style comments to search console sourcegraph#14476
• cmd+enter search: trigger search on cmd+enter in console sourcegraph#14508
• -bound-count comby
• hover info for query
• toml config file for rewriting

[github-actions]

Notifying subscribers in CODENOTIFY files for diff 213ce11...1a2217b.

Notify	File(s)
@sourcegraph/marketing	blogposts/2020/code-search-as-lightweight-on-demand-analysis.md

[sqs]

This is really cool. Here are some suggestions:

• It would be good to more clearly state why this is not just a worse staticcheck. You explain that in the text (and I get it), but it takes a lot of reading to find the exact reasons in various places.
• Related to the above, you should describe and emphasize the "lightweight workflow". You mention this once, but it should be fleshed out. Perhaps something like this (paraphrased)? "You know those times when you see a bug or a bad pattern in code, and you just fix the instance you saw? Chances are that the same problem remains unfixed in many other places. Developers generally have 2 ways to solve this problem: (1) linters (which are great for the super common, >99%-precision problems that merit writing a heavyweight lint rule); (2) better documentation, onboarding, and code review to prevent/catch these issues (which is imperfect and slow). But we're missing something in between. When you see a bug or bad pattern, you should be able to search for it across your code to see where it's lurking, and then write a fix, all interactively and without needing to be familiar with the compiler and linter APIs for the programming language. We're working to make this possible. Here's how it works, and here's how it stacks up against a popular Go lint tool (staticcheck)."
  • The "lightweight workflow" is the "you should be able to search ..." bit.
• I'm still concerned (even in that bit I wrote) that the comparison with staticcheck could make people think this is intended to replace staticcheck, no matter how much we explain that's not the goal. Could you pick some rules that would NOT make sense in staticcheck but that would make sense to find and fix using Comby patterns? The clearest/best example now is rules that apply to y/our own code, such as actor.FromContext(ctx).UID != 0 -> actor.FromContext(ctx).IsAuthenticated() and the custom eslint rules we have (which @felixfbecker is comfortable customizing, but most people wouldn't think to do).
• It would be nice if the linked Sourcegraph search queries (that display the search console page) have comments in them to explain what each rule is supposed to fix. (I think you've mentioned this, too.)

If there isn't a good way to avoid the staticcheck comparison, I think it's OK. I certainly do see the value of using staticcheck as a benchmark. My comments here around avoiding the comparison may be treating this blog post too much like a product anouncement and not enough as a "look at the awesome advanced search stuff we're working on" technical blog post.

[mrnugget]

This is really interesting, because it answers a question I've repeatedly had when looking at staticcheck.

I left some comments/suggestions that are all in the nitpicky/feel-free-to-ignore category.

On a general level, though, I think the structure of the blog post is a bit mixed: the first comparison between static checks & search reads as a pro/cons list, but then later there's more comparisons woven into the rest in the same pro/con tone (beginning of ## Adding more code checks).
I think you could improve the flow by following the shape you already have and move things to their appropriate section. From what I could gather that shape is roughly this:

1. intro: what are code checks?
2. can we use code search for this? yes, with limitations, so let's explore
3. example check turned into code search
4. turning more staticcheck checks into search
   4.1. approach
   4.2. results
5. takeaway (here's where I'd put the pro/cons summary)
6. addendum: what do we do with our search results?

[stefanhengl]

I really like the post! It makes a great case why universal code search is more powerful than a purely local setup. For me personally, I would have appreciated if the post stated its purpose/intent much earlier. Right now the reader has to read quite a bit before the story becomes clear ... but that's just nit-picking ;-)

[lguychard]

This is very cool! 👏 I left a few non-blocking style comments.