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 PascalCase and 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.
Best Answer
You also say:
Looks like you already have some buy-in from most of the team. Make creation of the document something that is done by all of you (all four if possible). If this is too time consuming, come up with your document and show it as a draft to your colleagues. Once all of you have agreed and finalized a version you are good to go.
A good place to start is a look at the different stylecop rules - you don't have to adhere to them all, but these will give you an idea of what your document should contain. As an added bonus, you can easily implement stylecop in your solutions and even integrate into an automated build (failing the build if there are violations).
To summarize:
Look at existing tools and standards to decide what you want in yours.
In order to avoid looking like a dictator, make the change a collaborative one.