itgmania212121/Docs/Devdocs/CodingStyle.txt

sm-ssc Code Style Guidelines
--------------------------------------------------------------------------------
AJ is biased, but prefers to edit text in SciTE and just uses Visual Studio when
necessary. "It's really slow!"

That being said, the sm-ssc code style guidelines are as follows:

1) Follow the current coding conventions set forth in the source code.
This means use tabs. AJ prefers tabs have a width of 4. Visual Studio and web
browsers assume tabs to be 8 by default. :/
Use of the tab character means you can define however wide you want it to be.

Use of the space character is allowed for complex alignment. There are many
examples of this in the code.

If it can be done in one line, do so:
int xTwenty(int factor){ return factor*20; }

Otherwise, follow what's in the code, namely...

for single line ifs :
if( somecrap )
	dosomethingelse();

for multi-lines:
if( anothercrap )
{
	omg();
	lotsofstuff();
}

Naming conventions seem to be Hungarian (of Apps or System, I do not know).

2) Remove any unnecessary whitespace. "Unnecessary" whitespace includes tabs
at the end of } characters, tabs that lead nowhere, like this one:
	
and keep in mind that this can be done with spaces too:
    
so watch yourself. Remove 'em all.

3) When making LOG->Trace()s in code, it's best to include the name of the Class
and Function in [], like so:
LOG->Info( "[NetworkSyncManager::Listen] Initializing socket..." );
You may not always need to do this, but it helps for clarity and sanity.

4) Comment style. (This is a preferred suggestion. You may choose to do whatever
you like, but it is recommended to follow this style when submitting code for
inclusion.)
// is preferred for one-liners
// and also blocks of text where the comment isn't too long.
// sometimes you'll find // comments longer than this thrown in there by AJ
/* instead of doing this.
 * when making a new line in a long form comment, start like this line.
 * and put the end where it fits. */

/*
 * doing this (first line blank) is discouraged, but is allowed in certain places.
 * Copyright notices use this style and should remain doing so; don't clean it up
 * in that instance. All new copyright notices should follow this style as well,
 * for consistency's sake.
 */
 
/* use of long comments for one line is VERY discouraged */
// usually, it will will get cleaned up into this style, but there are exceptions:

// exception #1: function arguments
void SomeFunction(size_t /*ACTUAL DATA TYPE*/)
// where you need to have it be /* */ or else it'll mess up.

// exception #2: #defines
#define /* you must use long form in defines, */ \
 // otherwise it won't parse the newline correctly (this will cause an error) \

// exception #3: .h files
/* ScreenTypicalExample - this always shows up like this. It usually is always one line, even when it extends past column 80. This is acceptible; Most people don't write novels here like I just did. */

// on comment length:
/* typically total 80 characters is the preferred width per line, like this one.
 * Sometimes, you can get away with sentences where a word or phrase hangs over the edge,
 * especially if you can guess the context without needing to scroll.
 * Pre-existing comments are usually trimmed to meet the 80-column width if they
 * go way overboard. */

5) There are no other rules (yet).