Niotso - Style guidelines

From Niotso Wiki
Jump to: navigation, search

Character encodings[edit]

Encoding: Encode your text files in ANSI (ISO 8859-1) unless there's a specific reason they need to be multilingual.
Newlines: Use Unix newlines in source code. Use Windows newlines in .txt files excluding the ones that are named CMakeLists.txt. A file with a name that is in all caps without a file extension should use Unix newlines.
Tabs: Don't use tabs in any source files except for Makefiles. The subtle issues that show up when you use tabs (gcc line numbering too short, different source viewers using tab-width 8) do not justify the filesize savings or the reduction of backspaces needed to delete a tab. Set up your editor to produce 4 spaces when you hit the tab key. And learn how to use the home and end keys.
Wrap-around: Don't let your text editor do wrap-around for you. Tell your editor to draw a faint line after the 128th character column, and do not let your code span to the right of that line.
Trailing spaces: You may wish to set up your editor to automatically remove all trailing spaces when you save. Notepad++ does this when you use Alt+Shift+S. It may be preferable to set up a shortcut such as Ctrl+T to trim trailing spaces; this too can be done in Notepad++ with Settings -> Shortcut Mapper (main menu section).


if(FileSize > 20){
for(unsigned i=0; i<5; i++){
while(i < 5){
do {
} while(i < 5);
    pressed = true;
    printf("Mouse moved\n");
case MSG_ERROR: {
    unsigned i;
    //Do something with i
} return -1;


At the top of every source file (.c, .h, .cpp, or .hpp) is a license reminder, either ISC License or GPLv3. If you are creating a new file, your name should be whichever online identifier of your choice, optionally followed by your email address in less-than/greater-than brackets. If you wish to remain anonymous, specify "Anonymous contributor".

Use camel-case for variable and function names. E.g. FileSize rather than filesize.

Except in a for loop with a constant upper bound, use unsigned integers if it makes no sense for the number you are dealing with to be negative. Leave off the "int" part of "unsigned int". Unless it's part of a struct or array, which will specifically have or exclude padding and won't clobber registers, use a natural integer rather than uint32_t or int16_t or short or anything like that, unless it makes sense. Use chars for strings, not uint8_ts. Don't ever use the short or long (or long long) keywords. short is always better represented as int16_t or uint16_t, and long has different meanings depending on your compiler, even on the same platform (*ahem* Windows).

Do not do "Circle myCircle", "Bone bne", etc. Do "Circle_t Circle" and "Bone_t Bone".

Don't do this:

101|            Graphics::CallThisFunction(x, sqrt(3), texture[Graphics::getid(TEX_BUTTON)], |<- Cutoff line
102|                                       max(foo_bar + OFFSET, SomeConstant),              |
103|                                       AUTODETECT_TYPE | MB_OK, 16777216,                |
104|                                       "Title - Name of the sim, male, a/s/l\n",         |
105|                                       &result);                                         |

Do this:

101|            Graphics::CallThisFunction(x, sqrt(3), texture[Graphics::getid(TEX_BUTTON)], |<- Cutoff line
102|                max(foo_bar + OFFSET, SomeConstant), AUTODETECT_TYPE | MB_OK, 16777216,  |
103|                "Title - Name of the sim, male, a/s/l\n", &result);                      |

Coding reminders[edit]

Please remember to use the static, const, inline, and __restrict keywords. const is not necessary (per se) in the body of a function, but mandatory for pointers/arrays/references passed as arguments whose contents will not be modified, and things at the global scope which will not be modified.

Per C99, restrict is automatically assumed for pointers of different types, so don't use it as such.

Please free all dynamically allocated memory and close all handles before shutting down the program to please valgrind. Doing so allows you to determine what is actually leaking to the end of the program. Do not write if(variable) free(variable) but do write if(variable) fclose(variable): freeing the null pointer is defined as no action, but fcloseing the null pointer is undefined and will actually segfault on Linux. When dealing with sockets, which use integer handles rather than pointers, close(0) is safe.


As the Linux kernel limits path lengths to 4096 bytes in UTF-8 encoding, your code should do the same.