C++ and C# naming conventions.

[deathismyfriend]

Hello i was wondering if anyone could supply me with a list of how things should be named with both C++ and C# ( mainly C#).

Any help is greatly appreciated.

 

[TriggerHappy]

http://msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

 

[GhostWolf]

Yeah just go by Microsoft's example and CAPS LOCK EVERYTHING.

That being said, you realize naming conventions are indeed conventions?
There are many, and some people like some more than others.

There are enough endless arguments about this online, please don't start one here.

 

[deathismyfriend]

There are enough endless arguments about this online, please don't start one here.

It wasn't to start an argument it was simply a question.

 

[Dr Super Good]

I do not know why Microsoft has guidelines like they are... I have a feeling they are aimed more at their internal programmers rather than for people programming software for their operating systems.

Every project I have seen has their own naming and style conventions. Some may use caps based types, others feature complexity restrictions while some just lack it and become a mess over time.

There is no one correct style you can use but there are hints.
* Constants have upper case names. This is pretty universally used and makes it easy to know that a value will not change over time.
* Direct use of primitive types avoided, instead derivatives of primitive types used from a header file. Although primitive types kind of have a defined behaviour by now, many people still regard them as platform specific and as such sub-typing is used to abstract this into a single easy to change value that can be adapted to the required compiler primitive type. C standard has some defined for this I believe such as uint32 which can be though of as a unsigned int.
* Use macros within code sparingly as they can generate compile time errors that are virtually impossible to understand. An example of an acceptable macro would be for native endian conversion. C++ users should rather use inline functions as these generate much more sensible compile time errors.
* Avoid coupling platform specific libraries to the bulk of your program code. Rather interact with an adapter to these libraries. This makes code considerably more portable as each platform may only need a new adapter as opposed to generating a huge mess of macros inside your code.
* Avoid reliance on structs or classes for I/O outside of caches. The size, layout and byte order are all platform and compiler coupled so can easily become a pain to manage. Caches do not care about this since they are generated by a platform for use on the same platform.
* Use a standardized comment structure persistently across all code. Do not explain obvious lines of code but do explain the code flow so navigation becomes easier.
* Avoid procedural coupling. Having 10 different copies of code that is 90% the same is completely unmanageable. Use a macro, inline or function to generate the code.
* Do not abuse headers. Each program code file should only include the headers it needs to compile and not every single header in the entire program. This means you should especially avoid Omni-headers which include every header. Not only does this reduce coupling making code easier to manage but also improves compile speed.
* Not everyone uses the same natural language that you do. Although your code and code comments can be in your native language, your program needs to be compatible with all languages. As such simple char types (usually 8 bit) should be used internally only (where you have strict control over the values used). All external interaction should use extended character types such as wide characters (usually 16 bits) or some form of Unicode. It is important to stick with one character convention across the entire program as re-encoding strings is very time consuming.
* Do not hard-code user read strings into the program code. Your program may require localization at a later time which is not possible if the code contains the displayed strings. Use some form of string table which translates a program code defined value (such as a string) into a localized string.
* If you are interrupted or distracted during programming you should leave a comment to indicate the area is not complete. With large projects it is very easy to forget that you still needed to make an extra line of code somewhere.
* Avoid complicated type casting. You should not need to nest multiple type castings in a chain if you are programming properly.
* Think of your function interfaces before starting to write code. Problems can be solved much more simply if you know what you are doing before hand.


Sure some of these are more general tips but they kind of do relate to overall program style.