Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code search is hard

blog.val.town

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Code search is hard

#121

Post by plugin-baby »

hiAndrewQuinn wrote: post #110

Basic code searching skills seems like something new developers are never explicitly taught, but which is an absolutely crucial skill to build early on. I guess the knowledge progression I would recommend would look something kind this: - Learning about Ctrl+F, which works basically everywhere. - Transitioning to ripgrep https://github.com/BurntSushi/ripgrep - I wouldn't even call this optional, it's truly an incredi…

Apart from speed, what advantages does ripgrep offer over git grep when searching git repos?

Re: Code search is hard

#122

Post by high_na_euv »

jillesvangurp wrote: post #117

It's why IDE and developer tool builders have long had the insight that in order to do code search properly, you need to open up the compiler platform as a lot of what you need to do boils down to reconstructing the exact same internal representations that a compiler would use. And of course good code search is the basis for refactoring support, auto completion, and other common IDE features. Easier said then done of…

>Easier said then done of course as tools are often an afterthought for compiler builders.

Except for Microsoft's Roslyn (.NET compiler)

https://willspeak.me/2021/11/24/red-green-syntax-trees-an-ov...

https://ericlippert.com/2012/06/08/red-green-trees/

Ive used Roslyn SDKs to build tools and it is really good

Re: Code search is hard

#123

Post by vladak »

metalrain wrote: post #104

I think you need to parse the code and build AST to make good search. Even then normalizing over different aliases, may not be simple.

The question is what code. In preprocessed languages there can be lots of ifdefs and such for various environments and architectures.

Re: Code search is hard

#124

Post by mcintyre1994 »

hiAndrewQuinn wrote: post #110

Basic code searching skills seems like something new developers are never explicitly taught, but which is an absolutely crucial skill to build early on. I guess the knowledge progression I would recommend would look something kind this: - Learning about Ctrl+F, which works basically everywhere. - Transitioning to ripgrep https://github.com/BurntSushi/ripgrep - I wouldn't even call this optional, it's truly an incredi…

I’d also point out that VSCode uses ripgrep for its search feature which is a great starting point.

Re: Code search is hard

#125

Post by tex0 »

datascienced wrote: post #112
hiAndrewQuinn wrote: post #110

Basic code searching skills seems like something new developers are never explicitly taught, but which is an absolutely crucial skill to build early on. I guess the knowledge progression I would recommend would look something kind this: - Learning about Ctrl+F, which works basically everywhere. - Transitioning to ripgrep https://github.com/BurntSushi/ripgrep - I wouldn't even call this optional, it's truly an incredi…

Also Github is a fantastic tool for searching code across repos, ones you may not even have cloned yet! Either public ones or org ones.

The new GitHub CS is pretty great indeed. Still not on par with it's role model, but getting closer.

Re: Code search is hard

#126

Post by callmeal »

jillesvangurp wrote: post #117

It's why IDE and developer tool builders have long had the insight that in order to do code search properly, you need to open up the compiler platform as a lot of what you need to do boils down to reconstructing the exact same internal representations that a compiler would use. And of course good code search is the basis for refactoring support, auto completion, and other common IDE features. Easier said then done of…

>With Eclipse all this was instantly and unambiguous ...

Still is, and is the main reason why a lot of us will never jump ship.

Re: Code search is hard

#127

Post by dikei »

jillesvangurp wrote: post #117

It's why IDE and developer tool builders have long had the insight that in order to do code search properly, you need to open up the compiler platform as a lot of what you need to do boils down to reconstructing the exact same internal representations that a compiler would use. And of course good code search is the basis for refactoring support, auto completion, and other common IDE features. Easier said then done of…

While Eclipse truely have an incredible incremental compiler for Java, IntelliJ's better integration with external build systems like maven and gradle, together with better cross-languages support, was what win me over.

Re: Code search is hard

#128

Post by nojvek »

You can do to_tsvector “plain” and keep the strings intact. No lemming, stemming.

We use plain tsvectors on a gin index and change the queries to allow prefix based searching. So “wo he” matches “hello world”.

Perhaps I should write a blog about it. Took me a few days to read PG documentation to get where we are at.

The only thing it doesn’t handle is typo tolerance.

Re: Code search is hard

#129

Post by actionfromafar »

shepherdjerred wrote: post #108
nosefrog wrote: post #99

Earlier quoted context omitted.

How did you avoid version hell? At Google, almost everything just shipped from master (except for some things that had more subtle bugs, those did their work on a dev branch and merged into master after testing).

Version sets take care of everything. A version set can be thought of as a Git repo with just one file. The file is just key/value pairs with the dependencies and major/minor version mappings, e.g. - Java 8-123 Lombok 1.12-456 ... A version set revision is essentially a git commit of that version set file. It's what determines exactly what software version you use when building/developing/deploying/etc. Your pipeline…

That sounds actually brilliant. Someone decided to brush less version stuff under the carpet.

Re: Code search is hard

#130

Post by burntsushi »

plugin-baby wrote: post #121
hiAndrewQuinn wrote: post #110

Basic code searching skills seems like something new developers are never explicitly taught, but which is an absolutely crucial skill to build early on. I guess the knowledge progression I would recommend would look something kind this: - Learning about Ctrl+F, which works basically everywhere. - Transitioning to ripgrep https://github.com/BurntSushi/ripgrep - I wouldn't even call this optional, it's truly an incredi…

Apart from speed, what advantages does ripgrep offer over git grep when searching git repos?

ripgrep author here.

Better Unicode support in the regex engine. More flexible ignore rules (you aren't just limited to what `.gitignore` says, you can also use `.ignore` and `.rgignore`). Automatic support for searching UTF-16 files. No special flags required to search outside of git repositories or even across multiple git repositories in one search. Preprocessors via the `--pre` flag that let you transform data before searching it (e.g., running `pdftotext` on `*.pdf` files). And maybe some other things.

`git grep` on the other hand has `--and/--or/--not` and `--show-function` that ripgrep doesn't have (yet).

Post reply on HN