Code formatting vs TDD

If you are a professional programmer, I'm pretty sure that you format your code. But could you convince someone who doesn't to do so? Not force, but make the person believe it's the right thing to do.

A while ago I was lucky to participate in a team-building game called "Council of the Marble Star". In this game you are divided in several teams. Each team has a certain amount of resources (like triangle and square pieces skin) and several cards with rules (like "after the first round teams will get 10 points for each square they own"). At the end of the game all the teams which have more than say 1000 points win, other teams lose. There are no other rules. You can trade your resources and information with other teams in any way you want. I played similar games before and knew that there are enough points for all teams to win. The only real problem for teams is to trust each other and share information. If no one shares, few teams win. If everyone shares, everybody win. There was another guy in the same team who also knew it. Given that, our team strategy was to convince others to share information so that everybody could win. We don't trade. We publish all our information for free. We tell people everything we know. Guess what happened. We lost. As well as several other teams. Why?! From the very beginning we knew how this game works. People we were trying to convince were co-workers, not strangers. It was just a game, not a matter of life and death. And still we failed to convince other teams to do the right thing. (In case I get into marketing one day and HR manager reads this... I learned the lesson, I can do much better now! I'll tell "how" on interview :))

While this is a funny story, it's not about programming.

Here is another story about programming. I was sitting next to my younger brother writing his first real-world program. ARP ping in C for Linux is a pretty cool start, isn't it? The program wasn't big. Just command-line arguments handling, scanning network in the same thread and printing results. The program worked fine. The only problem was that he did not use indentation. Ok, it was a "problem" from my point of view. Everything works, he understands code. Where is the problem? Why should he care that every piece of C code he can find on Internet has indentation? I think, it is not necessary to say that I failed to convince him to use indentation. (As a side note, he used a lot of procedures and no nested ifs, so the code didn't look bad.)

Can it be that there is something similar happening with other arguments? You know you're right, but you just cannot effectively communicate that. If it's the case, for me the first one on the list is TDD, followed by other XP and agile practices. It's true that the fact that you can't persuade someone to do X, doesn't make X a good thing. I know there are always new problems with the solutions which are supposed to solve your old problems. On the other hand, how do you know where is the line between obvious and not so obvious, line indentation and TDD? I'm serious. If I don't have lots of nested structures, if I can understand what I'm doing, all this code formatting stuff is just a waste of time.

Note to myself: read "Fearless change"