I wrote about this in my blog the other day.
C# Coding Conventions and Standards
I think as far as coding conventions go, the primary thing that contributes to the reliability, maintainability, and readability of code is naming conventions. The rest of the stuff is pretty standard.
There is not one "right" or "wrong" way with naming conventions. The key is consistency. For example, I always use camelCasing for parameters and local variables, I use camelCasing prefixed with an underscore for private / protected field members, and I use PascalCasing for class names, properties, events, functions, etc.
I generally shy away from hungarian notation as well for the sake of readability but I do think that in some scenarios it is helpful (I usually use hungarian notation for GUI types).
One side effect of sticking to conventions is that it is easy to keep track of what type of identifier you are looking at when reading code. For example, I can always rely on the fact that properties utilize PascalCasing while local variables do not, which saves me from having to scan back and find the definition of an identifier when reading code.
Having your team follow the same coding conventions and standards can help make your software more readable and more uniform by keeping things consistent and clean. This facilitates maintainability by allowing members of your team to be able to read and comprehend code written by co-workers more quickly without having to mentally run a background filter to interpret layout and style differences, etc. It also fosters best practices and can contribute to keeping your APIs consistent as well.
If your code is clean, consistent, and easy to read, it becomes more maintainable and less error prone.