http://tech.groups.yahoo.com/group/flexcoders/message/64415

As far as enforcing it…
http://blog.wordaligned.org/articles/2007/01/11/retro-fitting-coding-standards

You run into a border issue: where’s the border between, say, using variable type prefixes like sMyVariable:String and nMyOtherVariable:Number; and what style of brace indenting you use? If that border seems pretty clear, what about naming interfaces GeneralName versus naming them IGeneralName? Just about every coding style issue has implications somewhere, and arguments either way. I think if you have a code style, you should enforce it down the line — consistency is necessary, even if it’s on an issue like brace indenting, where there’s no real reason to choose one over another as long as you do choose one.

As for myself, I’m lucky: I’m the lead programmer at my agency, so I get to just write and hand the coding stylebook to new hires as a fait accompli. There’s no need to build consensus, just a “this is our coding style, please use it.” Of course, that doesn’t help with your question…

I recently left my old job for the very fact that there was all this ‘standards’ business going on. Legacy crap trickling down from idiots in suits telling us why we have to use ClearCase over SVN or we HAVE to have some broken DHTML crap on the homepage.

But in the same respect I certainly embrace standards when it comes to coding, clear down to the packaging schemes. Squigglies are taking it a bit far. I think the larger a team is, the more enforcement is needed. Especially if you have Old School ActionScripters working with J2EE => Flex converts.

I certainly advocate:
– code reviews
– peer programming and design collaboration (i.e. Agile w/ a little “a”)
– quick daily kickoff meetings to address who’s working on what and why and how better to do so
– an in-depth review of MVC and Cairngorm and WHY and WHERE you do WHAT (there are plenty of ‘Senior Flex Developers’ out there that still command-delegated tasks on the model?!?!?)
– an in-depth review of the MX framework especially if you are doing custom component development

On the flip-side, when interviewing for jobs, I feel a bit of negative tension towards companies that strictly enforce coding standards set by implementing pre-built frameworks. In my opinion, I feel that coding standards are something that should be set on a per-company/team basis. A framework that works great for Ecommerce applications won’t necessarily work well for multimedia applications. This is why it is important to have regular team meetings to discuss what opportunities are available and if it may be necessary to combine a set of standards to best fit the company/team/project.

I think that what everyone else said about having the entire team’s “buy in” when making any sort of decisions like this, is right on the nose. After all, that’s what being a “team” is all about.

Seriously though, I think the outcome you’re after is the right one, but as the other commenters indicate going straight for the jugular via management wont fly with the rest of the team. Get the team together, suggest you think “we” should hit up management to approve a company standard that “we” define. I assume you’ll get their backing (as keith said, if not I think it’s time to review the team rather than the code) then take the notion to management that you want approved time for standards setting (up front and regularly reviewed) with the team for the reasons you mention in the post.

Once done steer the group in a standards setting meeting, try to avoid any “my way or highway” go getters getting to mouthy and use it as an opportunity for everyone to contribute to and educate/be educated. I’ve done this in a few organisations i’ve worked for and more recently my own and it works well. Important to revisit, early and regularly at first because there’ll no doubt be some crap that needs to be changed/removed.