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?

  • 8
    I just use Ctrl-E, D ;)
    – Town
    Commented Jul 8, 2011 at 15:12
  • 1
    If this will not survive a run with the company formatting rules, the benefit is pretty small.
    – user1249
    Commented Jul 8, 2011 at 15:14
  • 2
    Why not make a program to auto-format your code, so you'll be happy and you won't waste time?
    – Jetti
    Commented Jul 8, 2011 at 15:15
  • 1
    Formatting makes it readable so it IS important, but definitely be "smart" - use the auto formatters. If that formatting isn't good enough - well then at that point you may be OCD.
    – Catchops
    Commented Jul 8, 2011 at 16:25
  • 3
    Well @Taylor your Laravel framework is amazingly pretty
    – Mr.Web
    Commented Jan 25, 2019 at 12:03

14 Answers 14


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?).

  • 1
    Why the all-bold second paragraph? Commented Jul 8, 2011 at 16:22
  • 5
    @FrustratedWithFormsDesigner: It's not emphasis if half the post is emphasised. :P
    – Jon Purdy
    Commented Jul 8, 2011 at 17:03
  • 2
    @Steven, @Jon - noted and editted.
    – user3792
    Commented Jul 8, 2011 at 17:20
  • 3
    Slightly ironic chain of comments. ;) Commented Jul 8, 2011 at 18:08
  • 2
    @StuperUser, more like lazy and getting things automated :)
    – user1249
    Commented Jul 8, 2011 at 18:16

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

  • 3
    +1: Total waste. Other people have different opinions and pretty and will reformat your code and also write complaining questions about why you don't follow their ideal formatting.
    – S.Lott
    Commented Jul 8, 2011 at 15:23
  • Putting all code on one line doesn't change its functionality, but using newlines does make it more understandable. Commented Jul 8, 2011 at 16:23
  • @Steven Jeuris: Are you talking about obfuscation? If so, why? The question didn't sound like that. It sounded like time-wasting. Where did you get the idea that the code was so badly formatted it was unreadable?
    – S.Lott
    Commented Jul 8, 2011 at 17:25
  • @S.Lott: No I am not talking about obfuscation. Putting all code on one line would be terrible obfuscation. :) I was trying to make the point that while not 'changing' anything, it can allow you to understand the code better. Look at Neville's answer for a more detailed explanation. P.s.: Furthermore I believe this is a really blank answer. Of course, when you change something which doesn't allow you to better understand the code that's useless, but that's highly subjective, and that is actually the question. Commented Jul 8, 2011 at 17:30

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


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....

  • You prevented me from writing my own answer. ;p Very well put! Commented Jul 8, 2011 at 16:28
  • +1 for noting that structure and naming conventions trump format in importance.
    – user3792
    Commented Jul 8, 2011 at 16:50
  • Very balanced answer +1
    – joel
    Commented Jan 18 at 19:28

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.


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.


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.


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.


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.


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:


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.


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.


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

Now, give yourself permission to act on it.


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


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.


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. :)


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?)

  • 2
    Thanks for contributing your first answer. Not sure who down voted it, but please take a quick look at the guidelines for answering questions on Stack Exchange Programmers programmers.stackexchange.com/questions/how-to-answer. Your response could probably be revised to those criteria to win an up vote or two. Commented Sep 2, 2012 at 2:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.