Highlighting.

I'm a big fan of highlighting text. (But only on computer screens, I hate highlighters on paper, and really don't understand those people who selectively highlight semi-random parts of books). To this end, I have the usual things set up, like my .vimrc enables syntax highlighting to show me when I've forgotten what C should look like. I've also started extending it to other uses. Like highlighting common bugs. It turns out to be handy when both writing code, and reviewing other peoples.

It's pretty simple to do in vim. For example..

highlight kmalloc ctermbg=red guibg=red
match kmalloc /k[mzc]alloc(GFP_/

highlight memset ctermbg=red guibg=red
match memset /memset.*\,\(\ \|\)0\(\ \|\));/


Now, go ahead and try that zero sized memset. Or a kmalloc with swapped arguments. The bright red text screaming AWOOGA in your face should be attention grabbing enough for you to instantly realize what's up as soon as you've written the erroneous line of code.

The above regexps aren't new either. I've posted blog entries before about how I recursive grepped for the latter across all 80gb of the Fedora source tree periodically. (And it still keeps turning up new casualties).

I've also extended mutt to catch this nonsense.


color index red default '~b "memset.*\,\(\ \|\)0\(\ \|\));"'


When paging through my inbox, when I see a mail in red, I know there's something silly in it, which needs further review. (Very handy for reading things like commit mailing lists, or code review lists).

Even if you don't write C, there are probably regexps for catching API misuses in other languages too, so the above principles should be useful. (I use vim/mutt almost exclusively, no idea how to make highlighting work with emacs etc, but I'm sure it's doable there too).

Syndicated 2008-08-27 16:44:52 from Dave Jones recollection of stuff that happened.