The Naming policy we will follow is the naming policy that Microsoft recommends for C#. Public features of a class will be denoted in Pascal case, and private features will be in Camel Case with no underscores in the names. Methods will be distinguished by the requirement of parenthesis requisite for the call. Because C# supports properties, public data may actually be methods, or turned into methods and so the programmer should not rely on that. It does not make sense to have data that are not properties distinguishable from those that are because it would mean that should in the future there be a wish to switch something to a property, then a lot of code will have to be changed.
Names will emphasize what they do, often what they do also describes a real world object, although there are some things such as GameState? which are of course abstractions. Long names are not a problem in an advanced IDE such as Visual Studios since tab completion can allow a programmer to type in a long name with only a few key strokes.
Booleans should be named such that one can ask the question is, for instance a boolean could be named Active, and thus you can ask the question is Active. The is will be omitted because C# naming policy discourages use of verbs in that sense. It should be obvious from the type signature that it refers to the boolean, and any other information is redundant and thus a violation of the DRY principle.
Documentation should occur for the public interfaces between different working parts when those working parts have been completed. Should different programmers being working on different parts of the project, than the interface between those parts should be decided beforehand and documented. That interface should not be set in stone, but only changed after agreement from all parties involved.
Functions, classes, and member variables should be documented using the triple-slash style as defined by Microsoft coding policy.