I want to know the rules of naming (AlwaysCapitalize, _underscore, firstSmallLetter, etc...) for each of Namespaces, Classes, Interfaces, Exceptions, Data Members, Methods, Variables, etc....also I would like to know:Are they standards?Do they differ According to the access modifiers? (public, private.....)What about compiler and library reserved formats?Also are they Language, IDE, or Framework relative?I only know that these rules exist, but don't actually know any.Any help would be appreciated.EDIT: OK, if the question is really wide, then I have to narrow my question:What are the naming rules of Classes, Interfaces, Data Members, and Methods in C# (and Java if possible).Also, inspired by Renesis's comment, I've created a wiki to write Coding Conventions, here's the link:http://codingconventions.referata.com/
Naming Rules: Standards, Reserved, and what do they depend on?
coding style;naming;coding standards;syntax;standards
Are they standards?In general, they are coding conventions not standards. Following the conventions makes reading the code much easier.  Companies and projects may adopt particular conventions as their standard.Do they differ According to the access modifiers? (public, private.....)This is dependent on the conventions in use.What about compiler and library reserved formats?Compilers and libraries commonly use underscores at the beginning or end of identifiers.  Programmers should avoid such identifiers unless they fully understand the implications.Also are they Language, IDE, or Framework relative?Different languages have different conventions.   Some languages have competing conventions.  Most frameworks will have a convention, but not all frameworks have the same convention.  IDEs may provide support for coding conventions.  Many have add-ins which will allow the use of style validation tools within the IDE>EDIT: Java has a recommended coding style now available from Oracle.  I don't work with C#, so I don't know if there are competing standards to the MSDN C# coding standards.  These would be a good starting point for your own standards.   When working with existing code try to follow the same conventions as the current code.  Working with code that has been coded with a variety conventions can be very confusing. You may find it useful to be familiar with a number of conventions.  You will likely encounter a number of them as you work with different code bases.  When working on new code select a set of code conventions and stick to them.