I've written up a number of "guidelines" for dev teams in the past, generally speaking it's something you really should do, and is also wildly impractical.
Why should we do it?
Simple, you can't afford to have everyone doing the same thing in a different way on your team as it gets cludgy and hard to maintain. You also want to help the new guys avoid the sort of mistakes it takes only a minute to address.
It's also good even in more experienced teams to come to a consensus on how to do something and stick to it for sake of maintainability and readability purposes.
What's impractical about this?
A guide itself is hard to use. Someone will read it, and forget it quickly as generally speaking we retain less than 20% of what we read. In addition telling people to always "check the guide" does you no good if the guide only covers a small amount. Of coarse making the guide cover almost everything is simply impractical.
Even if you were to establish the guide that covers everything it would need to change as technology and your company grows and changes.
Limit the guide
For the "new hire" guide you want to keep it strictly to things unique about your company. How do you test? Where does your code live? What's the proper chain of command? How do requests work their way to the devs? What is the completion process? What documentation is expected of them? etc.
Use other tools
There are countless things you'll be tempted to add to your guide that you simply shouldn't. Coding standards, best practices, etc. These are best left to tools that are more functional than a guide. For those of us in C# setting up resharper to handle your coding standards takes the burden off the individual. You can also setup a wiki to document your internal systems are processes.
My advice as a new team lead is you CAN NOT force your way of coding on others. We devs just don't take being told how to do things well and you'll probably just get heavy resistance. The key is getting your team invested into standards. Set the standards as a team. When you need to set a standard (for example how you'll publish projects) you should sit with the team and work out as a team what makes the most sense, then that is your standard (documented in your tool of choice) until such time that the standard needs to be updated due to changes in the way the company does business or technology.