Software coding standards

In the 2007 Microsoft TechEd conference I joined a Birds of a Feather, that is, a discussion session, on software coding standards. The discussion was going through those 'interesting' topics: indentation, convention of variable names, etc. At one point the presenter/moderator showed this C# example:

int a = 3.14;

And asked the audience to comment. I guess the first person said that the variable should be called pi. The second person said it should be PI, in uppercase. Then the third person said that the type should be a double and not an int.

double PI = 3.14;

My position, which I stated at some point, was that the discussion was going in the wrong direction, that these kind of standards are a waste of time. I was crucified by most, and congratulated by a few after the session. More on that below...

This is how my thought progressed.
1- It shouldn't be
double PI = 3.14;
The developer should use Math.PI instead of creating a variable.
2- Why do you need to reference PI? Are you sure you are coding against the requirements?
3 - What are the requirements? Are you sure the requirements reflect what the customer wants?
4- Who is the costumer? Is the customer sure that the requirements and what they want address what they need?

Going back to the discussion, people were angry with my 'disregard' for coding standards because they had high costs of software maintenance, low levels of programming productivity and so on.
"If everyone codes in different ways nobody will understand each other's code."
"I opened source code of 20 years ago and there was no comment."
"If only we could unify our coding standards we could fix more quickly the bugs"
etc

My intuition: they were looking for a scapegoat for their problems. With the average American IT manager living in a modernist and consumerist society it's natural to look for quick fixes to problems. Here are some other items for the discussion:
- If you are having problems with maintenance, take a look at second look at the source. Would developers create better software if they were trained? Is training not accessible to many or is training in general not effective in this problem?
- Instead of debating coding standards, why not speak about software patterns and reuse?
- What about the project life cycle? Are developers creating bad software because of the lack of software methodologies?
- Are developers creating bad software because of time pressure and an office culture of competition instead of cooperation?
- How many times do developers reinvent the wheel because they are not humble enough to reuse other software? How many times do developers reinvent the wheel and create bloated code because they want to create problems only to solve them later to justify their position and work?
- What about time to market? At times it is better to ship quickly 'bad' software. Or better, to ship simpler (well documented, well thought) software.
- (Making a point just for the sake of discussion: ) It's better not to comment the code so that whoever reads it after will really think about he/she is reading and make an effort to better understand the code.