Live data from Hacker News

Don’t underestimate grep-based code scanning

littlemaninmyhead.wordpress.com

81–90 of 122 posts

Re: Don’t underestimate grep-based code scanning

#81
post #74
post #52

Don't use grep. Use ag[0], which is specifically designed for searching code. It's much faster, honors .gitignore, and the output can be piped back through grep if you like. ag FooBar | grep -v Baz It's in brew/apt/yum etc as `the_silver_searcher` (although brew install ag works fine too). 0: https://github.com/ggreer/the_silver_searcher

+1 Here's why: ag provides sane default and settings for developers. grep is ubiquitous and great, but to do what most developers want it requires some guidance, whereas ag focuses on being what you want most of the time. What I mean by that is that I enjoy the smart-case sensitivity (as in, if there are not caps in my pattern, then it defaults to case-insensitive but if I have any caps in my pattern, it uses case-se…

> it also didn't provide as good support for filename searching

Could you elaborate on this? Is it because you need to type more? If so, I'd suggest one of two things. 1) use `fd` for searching for files, which is dedicated to that purpose. 2) define `alias rgf="rg --files | rg"` (or similar) and use `rgf foo` just like you would use `ag -g foo`.

Re: Don’t underestimate grep-based code scanning

#83
post #3

One thing which was not immediately obvious to me for a while: the stricter your language’s formatting is, the easier it will be to grep source code. I work a lot with Go, where all code in our repository is gofmt'ed. You can get quite far with regular expressions for finding/analyzing Go code. (And when regexps don’t cut it anymore, Go has excellent infrastructure for working with it programmatically. http://golang.…

Related to this, it is generally a very good idea to be strict when naming functions, parameters, variables, etc. so that each concept has exactly one name throughout the codebase.

Also, please think twice before using OO classes as a license to give all your methods useless names like "get", "add", "open", etc.!

Re: Don’t underestimate grep-based code scanning

#84
post #82

Hold on, strncat and strncpy are considered dangerous too, now? Not just the older versions without the size_t num argument?

They don't \0-terminate the target on overflow, so you still need to test for that condition. So most people will have a wrapper around those to ensure the \0 is there.

Re: Don’t underestimate grep-based code scanning

#85
post #84
post #82

Hold on, strncat and strncpy are considered dangerous too, now? Not just the older versions without the size_t num argument?

They don't \0-terminate the target on overflow, so you still need to test for that condition. So most people will have a wrapper around those to ensure the \0 is there.

I think BSD has strlcpy and strlcat for exactly this reason

Re: Don’t underestimate grep-based code scanning

#86
post #3

One thing which was not immediately obvious to me for a while: the stricter your language’s formatting is, the easier it will be to grep source code. I work a lot with Go, where all code in our repository is gofmt'ed. You can get quite far with regular expressions for finding/analyzing Go code. (And when regexps don’t cut it anymore, Go has excellent infrastructure for working with it programmatically. http://golang.…

Related to this, it is generally a very good idea to be strict when naming functions, parameters, variables, etc. so that each concept has exactly one name throughout the codebase.

But how do you effectively orhanize/enforce this for a code base of several million LOC where geographically distributed teams are working on different ends of the system all the time?

The amount of cross team coordination is staggering.

Re: Don’t underestimate grep-based code scanning

#87
post #3

One thing which was not immediately obvious to me for a while: the stricter your language’s formatting is, the easier it will be to grep source code. I work a lot with Go, where all code in our repository is gofmt'ed. You can get quite far with regular expressions for finding/analyzing Go code. (And when regexps don’t cut it anymore, Go has excellent infrastructure for working with it programmatically. http://golang.…

Another thing that's not immediately obvious is the longer your search string is in grep, the faster it will find your results.

Can you explain why that's the case?

Re: Don’t underestimate grep-based code scanning

#88

Earlier quoted context omitted.

Another thing that's not immediately obvious is the longer your search string is in grep, the faster it will find your results.

Can you explain why that's the case?

I think it's because there are fewer potential substrings to check for matches, since most of the characters you add to a regex to make it longer also add to the minimum length of the expressions that it can find

Re: Don’t underestimate grep-based code scanning

#89
post #3

One thing which was not immediately obvious to me for a while: the stricter your language’s formatting is, the easier it will be to grep source code. I work a lot with Go, where all code in our repository is gofmt'ed. You can get quite far with regular expressions for finding/analyzing Go code. (And when regexps don’t cut it anymore, Go has excellent infrastructure for working with it programmatically. http://golang.…

I find that line wrapping frequently prevents me from getting complete coverage though. So it works for some cases, not for others.

But I do love auto-formatters. (I'm doing web dev at the moment, so Prettier.) It is freeing to not worry about spacing, line breaks, parens, etc.

All I have to do is give the computer a valid AST and it does The Right Thing.

Re: Don’t underestimate grep-based code scanning

#90

Earlier quoted context omitted.

Related to this, it is generally a very good idea to be strict when naming functions, parameters, variables, etc. so that each concept has exactly one name throughout the codebase.

But how do you effectively orhanize/enforce this for a code base of several million LOC where geographically distributed teams are working on different ends of the system all the time? The amount of cross team coordination is staggering.

Documentation, I think.
Post reply on HN