No - being obsessed with making code look pretty is missing the point.
Here are some pieces of wisdom that I found useful:
Ask Why Code Needs to be Tidy.
You may or may not be wasting your time depending on your definition of pretty.
The Fundamental Theorem of Formatting
says that good visual layout shows the
logical structure of the programme.
Making the code look pretty is worth
something, but it's worth less than
showing the code's structure.
[pg 732, Code Complete 2nd Edition, Steve McConnell]
If You Use Concurrent Versions System to Track Changes in Code - Don't Mix Code Formatting Changes with Logical/Adding Features Changes within the Same Commit.
It'll make changes harder to spot and
will cause unnecessary merge conflicts
if other team members are editing the
file. If you must make formatting
changes, check that other team members
are not working on that file.
[Paraphrased, Pg 93, Pragmatic Version
Control Using Subversion , 2nd
Also Martin Fowler talks about 'wearing two hats' and switching between them throughout the day. One hat for adding features, one hat for refactoring.
- You consider adding a new feature (Feature Hat)
- You peruse the existing code to gain understanding, tidying as you go.
- Commit the Changes.
- Add the feature. (Feature Hat) and so on....
[Paraphrased pg 57ish, Refactoring, Martin Fowler]
So, don't spend hours trying to prettify the whole code base. Just prettify enough code that you need to in order to add the next feature.
In short... leave each piece of code in nicer state than when you first arrived.