First a bit of background: My current development manager is taking another opportunity the end of this week, leaving our team with four fulltime developers, a part-time intern and a web designer (who is technically part of Marketing, not AppDev). At this time we aren't promoting or hiring a new manager.
The previous manager never would take the time to come up with a set of coding standards to adhere to (to put this in perspective: My one-year anniversary at this job is in two weeks and I've been talking to him about standards since I started). Due to this, all of us four developers write code our own way: Some of us follow the Microsoft naming conventions for .NET, some use Hungarian notation, some use a mix (e.g. mixing
camelCase for parameter names), and it's entirely random when you open a code file what standard it will follow - about the only thing consistent is that braces are on separate lines.
Two out of my three co-workers have approached me to create a standard coding document that we can use and enforce moving forward (although I am technically not the most senior developer, the fourth developer having been here for several years, two co-workers and the intern look to me for advice/guidance but we do not have a team lead). I have been meaning to do this for a while but the now-departing manager would always put it on the backburner; his departure now gives us a chance to take some time and configure things correctly to facilitate a proper software environment and not the rushed hodgepodge we currently have.
How should I go about doing this and introducing this standard to my team without causing friction? I don't want to make it look like I'm "taking over", although were I offered the manager position I would accept it. As I said two out of three other developers are on board with me creating one, but the fourth (the true "senior" in length of time) may or may not accept it. I plan to start with the .Net conventions from Microsoft (e.g. do not use Hungarian Notation), add some personal preference (e.g.
_camelcase for fields) and specifically call out certain strange practices we use here as not to be used (e.g. naming a class with an underscore at the start), but what else should I include? I don't want to get into architectural guidelines as that will cause friction and we have a very large, and smelly, existing codebase that wouldn't adhere to it, and we're nowhere near at the point of coming up with a refactoring strategy.
To summarize: Beyond basic naming conventions what, if anything, should I include in a coding standards document (examples would be great - I haven't managed to find any concrete examples of what such a document should look like), and how should I present it to my team without sounding like the new dictator.