Most IDEs will format your code for you these days, making sure that your braces are always where you want them to be, and that everything is indented properly. Some will do even more for you. Eclipse provides save actions that will make sure that you always include braces around blocks, and even sort your methods and declarations for you.
How much control do you turn over to your editor? Lately I’ve been inclined to let the editor do as much as it can. Aside from aesthetics, I’ve decided that the single most important advantage offered by consistently formatted and organized code is high quality diffs when you’re reviewing your code history.
If you enforce the same formatting and organization on your code, theoretically the revision history for a file will contain only substantive changes. That provides real value as far as I’m concerned.
The only disadvantage I’ve found so far is that if you use save actions to organize your code and you save a file that has conflicts marked, the save action will make a huge hash of it. (Maybe Eclipse should have an option for disabling save actions when saving a file that has errors.) That’s easy to reverse, though, with an Undo.
Anyone else have an opinion on this? I’m finding myself wishing that I had a tool that does as good a job organizing and formatting Ruby code as Eclipse does with Java.
September 7, 2008 at 12:57 am
Maybe this is not the answer to a question you haven’t asked – but in the few times I needed to compare text files, UltraCompare was very helpful.
http://www.ultraedit.com/products/ultracompare.html
September 7, 2008 at 7:18 am
I’m mostly coding actionscript these days in the Flash IDE, and that does a terrible job of formatting my code. It strips out most of the line-break whitespace, which drives me nuts.
September 7, 2008 at 10:35 am
I think things like this are almost essential, particularly in a team. I try to be very aware of code that I check out because I find colleagues are not quite as aware of the implications of any changes they make as I might like them to be. It also serves as a level of code review. If I have to mentally parse out all the diffs based on formatting quirks, I’m wasting a lot of time and I’m more inclined to skip that review when I’m neck deep in my own work. But once I start doing that I very quickly come to regret it.
September 7, 2008 at 9:19 pm
FWIW, one of the things we put into Jazz was the ability to hook code conventions into your team’s process so you could do things like verify there are no unused imports before delivering a change. Naturally it’s configurable and extensible so you can plug in different rules.
I had always thought of this to produce standard, hygienic code based on team conventions; I hadn’t considered the non-trivial change deltas angle, but it’s a good point.
September 7, 2008 at 9:36 pm
I’ve started using tools like perltidy because you can check the config file into your repository along with the code. High-quality diffs were one of the justifications for this – more consistent formatting makes every single thing you do easier by minimizing the “parsing” overhead.