KnifeMissile

Now that we've already answered Prince's question, I don't think threadjacking is a problem, anymore. Jack away!

So, let's talk more about coding standards, since you feel that being a Nazi about it will help you.

Perhaps I should mention that while I have little formal education in software engineering (I studied math in university), I have had a lot of experience as a software engineer while working on large projects for billion dollar multinational corporations...

First, lets discuss the points you brought up for coding standards.
Code quality is a catch all term. What do we mean when we talk about quality code? It's no more meaningful than to simply say it is good code. While this is not a useless statement, for we often see examples of good code and bad code, it's much too vague to be used as a supporting point, since we are talking about what's "good" about coding standards. It's just as meaningful as saying "it's good because it's good."
Readibility is an aesthetic opinion. Like you've discovered with n0nsensical, what's readable to one person it not necessarily readable to another.
Uniformity is a tautology, in this context. When we talk about coding standards we are, by definition, talking about uniformity. If you're following a standard then your code is uniform, right? Again, it's as useful as saying "you should follow a standard so that you will be following a standard."

Now, while it may have look I've totally ripped apart everything good you've ever had to say about coding standards, let me say that they aren't toally baseless. If i had organized my source code so that it looks like a choo-choo train, or if I named all my variables _, __, ___, etc... (a perfectly legal thing to do in C/C++), there will be few people who will contest that this is unreadable and, thus, low quality code. It will still be uniform, however, 'cause that was a truly useless statement.

So, what are we really talking about? If you put in some effort into making your code readable, like decent variable names and some indentation,
then most people will agree that the code is human readable. What if different parts of the code were written using a different style. It's still indented and the variables will still have meaningful names (we'd hope). Will it really throw you off that much? Will you suddenly throw your arms up and say "I can't read this garbage, it's all different!"
Really?

What if you use third-party code? Or code licensed from someone else? Code bought from someone else? Or you're trying to work on a project for the first time? Maybe an open source project? What if you're a consultant helping some team with their project? If they follow a different standard than you, does that mean you're screwed? Will you say, "I'm sorry, I can't help you. I can refer you to someone who's familiar with your style, though!"
Will you then say to yourself "I'm glad I accustomed myself to the One and true God given coding standard and that I've been a total Nazi about it all my life! It has sure helped my career!"

Of course not. This is all silly and I hope you found it amusing but there is a real point in all this. Does it really matter that much? I question whether it matters at all. Here's something to actually concern yourself about, now that you had brought it up...

Maintainability is essential to any programming project. Even if you are writing "throw away" code that you never expect to come back to again, you will be "maintaining" your project while you are writing it, so it's never a waste of time. But what does it take to write maintainable code? Surely, if I follow a coding standard, my code will be maintainable, right?
I wish it were that simple.

Let me offer you two simple ways of increasing the "maintainability" of your code that goes leaps and bounds beyond anything your choice in coding style will ever do for you.

Code on a strict "need to know" basis.
This includes ideas like implementation hiding and data abstraction.

Avoid parallel information whenever possible.
This includes ideas like code reuse, and principles like avoid premature caching. (code reuse just says it all, really)

It's one thing to read about them in books (like I once did) but it really hits home when you've been saved or bitten in the ass by the presence or absense of these practices.
I'd write more (like how these things actually make your code more maintainable) but I've written enough, I have things to do, and you already know, at least, half of this stuff...