Is there any benefit to obsession with making code "look pretty"?

Question

Sometimes I spend ridiculous amounts of time (hours) agonizing over making code "look pretty". I mean making things look symmetrical. I will actually rapidly scroll through an entire class to see if anything jumps out as not looking "pretty" or "clean".

Am I wasting my time? Is there any value in this kind of behavior? Sometimes the functionality or design of the code won't even change, I'll just re-structure it so it looks nicer.

Am I just being totally OCD or is there some benefit hidden in this?

Answer 1

Use an auto-formatter. If you really are spending that much time manually editting the code, I would be willing to guess you are not very challenged/bored, because there is absolutely no reason for it. Ctrl+K, Cntrl+D in VS will format an entire document. You can use something like Style Cop if you want something a bit more heavyweight.

It is good to have pride in your code, but not when it comes at the expense of being smart (looking for the most efficient solution. In this case, using a tool to automate a tedious process) and getting things done (what else could you have worked on during those hours?).

Answer 2

If you are not changing anything that allows it to be better understood, then yes, you are wasting your time.

Answer 3

Nothing hidden, pretty code is easy to read and easy to maintain.

"Hours" seems a little excessive though unless you have a huge codebase. Not everything has to be perfect it just has to be good

Answer 4

It's a matter of judgement; if you're spending hours, I'd say you're going over the top. However, there are things a human can do which an auto-formatter can't, and things you can do to make your code more readable that are hard to capture in corporate coding standards.

For instance, when declaring variables in a class, I like to have logical groupings - it makes it easier to follow the logic.

Code is usually considered "write once, read many", so making the reading experience pleasant is a good habit - but layout in my opinion is far less of an issue than clear naming conventions, clean abstractions, and well-structured method signatures.

I have seen beautifully formatted code which caused severe WTF moments because the underlying thought process was flawed. If you have hours to spend, I'd spend it on design and refactoring, rather than layout....

Answer 5

No you are not being totally OCD. The greatest compliment i have ever heard as a programmer was, "Your code is so clean that my little brother could figure it out."

Someday someone is going to have to support your code. Clean code is much easier to support. And some day that may be you. In 6 months or a year you are not going to remember what you did. But if it is clean and easy to read It will come back quickly.

That said if the code is garbage, it does not help to be pretty garbage. But if it is structured well and just has functionality issues then it will be much easier to improve the functionality.

Answer 6

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 Edition]

Also Martin Fowler talks about 'wearing two hats' and switching between them throughout the day. One hat for adding features, one hat for refactoring.

1. You consider adding a new feature (Feature Hat)
2. You peruse the existing code to gain understanding, tidying as you go. (Refactoring Hat)
3. Commit the Changes.
4. 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.

Answer 7

If it is purely formatting, you are probably better off investing some time in teaching a pretty-printer how you want your code formatted. That is somewhat costly up-front, but I imagine you'll recoup that timer in 2-3 uses.

If it's actual refactoring, possibly not. Conceptually clean code tends towards being easier to modify going forward and having "always clean" lessens the temptation to let something through just because there's other smelly code around.

Answer 8

It helps a little, but it's not worth spending a lot of time on it. Also make sure your improvements also do add variable scoping, RAII, group copy/pasted code etc. If you do all of that, it becomes 1000x easier when you have to understand what the code does after a year or so.

Answer 9

You should produce clean code, but it shouldn't take hours.

For C, there is the gnu-program gnu-indent gnu-indent, in eclipse, there is at least a codeformatter for Java, and I guess there are tools for most other languages too. It should be a few clicks to indent a file correctly, and a few minutes, if you like to violate the rules for specific purposes - like I do for short switch-case-statements:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

which is hard to specify.

Answer 10

If you think something looks clean by skimming it, you are concentrating on something superficial which can be automated.

Read this classic article on "Making Wrong code look wrong" and you'll see exactly why people commonly think indentation (which can be done automatically) is trivial:

http://www.joelonsoftware.com/articles/Wrong.html

Particularly this list:

OK, so far I’ve mentioned three levels of achievement as a programmer:

1 . You don’t know clean from unclean.

2 . You have a superficial idea of cleanliness, mostly at the level of conformance to coding conventions.

3 . You start to smell subtle hints of uncleanliness beneath the surface and they bug you enough to reach out and fix the code.

There’s an even higher level, though, which is what I really want to talk about:

4 . You deliberately architect your code in such a way that your nose for uncleanliness makes your code more likely to be correct.

This is the real art: making robust code by literally inventing conventions that make errors stand out on the screen.

Answer 11

You recognize the problem (compulsive behavior) and the symptom (formatting obsessively).

What about the cause and cure?

• Are you working too many hours?
• Are you frustrated, bored, anxious?
• What is your next task? Is it something you don't want to do?
• When did you last have a vacation? Promotion? Recognition for an accomplishment?
• Is it a burn out related issue?
• Are you on a Death March?

Sometimes these symptoms are a sign it is time to make bold changes or move on.

Despite its downer title, Yourdon's book has many helpful suggestions and for many organizations, is making a pretty real description.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

You seem pretty insightful and I think you might know the answer.

Now, give yourself permission to act on it.

Answer 12

"Hours"? Well, I'd say your answer is "and", not "or": yeah, you're being OCD, but there is some benefit to it.

Probably.

Does it make your code easier to read fast? Does it make it easier to skim, to figure out what stops and starts where, to find functions, variables, etc? Does it make the way your code works clearer? Does the process of prettying-up force you to revisit some design decisions, and prune dead code or strip-out half-baked solutions you ultimately abandoned? If so, it absolutely has value.

On the other hand, if you've figured out some perverse way of appealing to your own sense of aesthetics without actually making your code easier to work with, then yeah, it's a big damn waste of time.

As for me, I tend to fall on the OCD end of this myself -- but I'm not gonna stop. The act of providing documentation for a class or function forces me to think about how the thing really works -- I'm writing it so that somebody who isn't me can understand it, after all. And if I find myself tossing in a bunch of caveats and warnings and apologies for why the code works the way it does, that's a pretty strong warning it needs one more round of tweaking before I declare it finished.

Answer 13

First nothing wrong in making your code look pretty because eventually you want to be proud of you creation and presentation/formatting of code is a part of that.

However I'd be careful in not over-formatting your code for the sake of your coworkers or future developers. Pretty to you might not be pretty to me. :)

Answer 14

Holy Bovine!
You folks have never heard of indent?

its a code formatting utility that been around for over 20 years. Its got a mega-bucket of options so your code can be formatted anyway you want it, automatically.

ermm - but it only works on C and some but not all C++.... (wtf? why doesn't GNU upgrade it?)