October 2009

ack: grep for programmers

Peter McCurdy, 26 October 2009

If you find yourself using grep a lot to search through code files, you should probably take a look at ack (packaged as ack-grep in Debian and Ubuntu). It’s like grep, but optimized for searching through codebases, particularly ones that involve multiple languages.

As an example, say you have a project that involves a mix of C++ and Python files, and you want to find all the occurrences of “foo” in just the Python files (this happens to me all the time these days). With grep, you have to say find . -name \*.py | xargs grep "foo", or thereabouts, whereas with ack it’s just ack "foo" --python. For languages with multiple possible extensions (e.g. Perl, C++), this is even nicer.

OK, maybe you’ve already set up all the grep aliases you could ever want, so never type those ugly command lines any more. Even so, I still love ack, because the search results are that much more readable: the filename only shows up once per file, with each match within the file having only the line number taking up space, like so:

$ ack Hello
hello.c
3:// Prints "Hello, world!"
6:    printf("Hello, world!");

I find this makes the results significantly more readable. And what I haven’t tried to replicate above is how it highlights both matches and the filename with a bit of colour, making it even easier to scan.

And on top of all that, “ack” ignores your editor’s swap files by default, and is 25% less typing than “grep”! So give it a spin, I started liking it right away.

4 Comments »

PyChecker

Mark Côté, 15 October 2009

Present Python to a group of coders used to C/C++, and the objections are pretty familiar. They almost all revolve around Python’s typing, specifically that it is dynamic and thusly only evaluated at run time. “You’ll be delivering products with all sorts of potential bugs!” My knee-jerk reactions when put on the defensive like this also follow standard patterns, such as “a compiler isn’t a substitution for thorough testing” and “so you never type cast?” But those reactions never seem to win the argument on their own because there really is no denying that Python introduces a source of errors that are caught very quickly in statically/normatively typed languages. One friend of mine objected to using Python for a weekend programming event because he didn’t want to be searching for errors like this at 2:00 am:

broken = False
...
try:
    thingy.configure()
except:
    borken = True
...
return broken

He pictured himself debugging thingy.configure(), trying to figure out why it wasn’t generating an exception while it was obviously failing, never noticing that he wasn’t setting the correct variable in the exception handler. I’m sure that many Python programmers would loudly suggest that the potential of such errors is minimal if one is careful, and indeed is an acceptable price given the speed of development conferred by Python, but would secretly be thinking of times they were burned by exactly such a mistake.

If you can, however, find these errors by carefully scanning your code, why can’t this be automated? And indeed it already has been! PyChecker “finds problems that are typically caught by a compiler for less dynamic languages, like C and C++.” And it does a pretty bang-up job too. I just found a few silly mistakes in my app, down code paths that (apparently) aren’t used very often. Hey maybe inadvertently it’s also a good tool to determine how much effort I’ve wasted coding features and error handlers that are never used…

No Comments »