Code Cosmetics With Komodo and vim
The source code for the Mozilla Add-ons project tries to follow the PEAR Coding Standards. One of these standards is to use 4 spaces per level of indentation, and no tabs.
Over time, unfortunately, some files start to contain a significant amount of mixed-up indentation (both from badly set-up IDEs and third-party contributions that came with tab indentation but went un-noticed). That’s both tedious and error-prone to fix by hand.
A similar problem poses trailing whitespace. While it’s just annoying in general, especially in HTML template files, it also increases page size unnecessarily by leading to more bytes transmitted on the wire, with no benefit to neither the users nor the developers.
Luckily, there are two quick fixes for these problems in both the editor vim and my IDE of choice, Komodo:
To remove tabs and replace them with spaces…
- in Komodo, select a code block, then click Code -> Untabify Region.
- in vim, type
:%s/\t/ /g(those are four spaces) — or, as oremj points out in the comments, you could just to:retab.
And to wipe out trailing whitespace…
- in Komodo, in Preferences -> Editor / Save Options, activate the option “Clean trailing whitespace and EOL markers”. Then open your document of choice and just save it again. However, when writing patches, you might want to refrain from keeping this option on at all times: It might result in confusion if a lot of lines are touched that do not have anything to do with the current patch. I wish there was a one-time way to run this, instead of a config option.
- in vim, type
:%s/\s\+$//gwhich the regex-savvy among you have quickly decyphered as: “in the entire document, replace all one or more whitespace characters that are followed by a line ending with the empty string”.
Happy cleaning!
In Eclipse, I use the “Format Source” feature for the same purpose.
In order to clean-up code and perform changes to the code base, we started to check in two revisions for the change: the first one if the code was heavily reformatted and the second one for the actual change.
That makes it easier for everyone from the team to track changes through diffs and does help us to clean up a bunch of ugly formatted legacy code.
In vim you can also just do :retab.
Jeremy: Thanks, I didn’t know that!
Jean Pierre: That’s what I usually do, too. Though I make a patch with content first, then sneak in the format changes when getting a positive review and committing that. Either way works. Only disadvantage of “sweeping” files sometimes is, when something breaks, people might `svn blame` you and then decide that you broke it, because you fixed the format on that specific line. That’s unfortunate.
> people might `svn blame` you
Oh, I think I can handle that.
The occasional being-blamed-for-code-you-didn’t-break is less annoying than having to crawl through badly written, undocumented and buggy code every day.