{"id":22796418,"url":"https://github.com/macmade/xs-labs-style-guide","last_synced_at":"2025-04-19T13:13:12.552Z","repository":{"id":140403044,"uuid":"12135822","full_name":"macmade/XS-Labs-Style-Guide","owner":"macmade","description":"XS-Labs Coding Style Guide","archived":false,"fork":false,"pushed_at":"2024-11-04T17:50:53.000Z","size":110,"stargazers_count":25,"open_issues_count":0,"forks_count":6,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-03-29T08:11:20.048Z","etag":null,"topics":["assembly","c","c-plus-plus","code","coding-standards","coding-style","conventions","csharp","guide","objective-c","reference","swift"],"latest_commit_sha":null,"homepage":"http://www.xs-labs.com/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/macmade.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE.md","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"macmade"}},"created_at":"2013-08-15T14:08:47.000Z","updated_at":"2024-11-04T17:50:57.000Z","dependencies_parsed_at":null,"dependency_job_id":"13fc484e-2320-4d7e-865e-907645d39f8f","html_url":"https://github.com/macmade/XS-Labs-Style-Guide","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/macmade%2FXS-Labs-Style-Guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/macmade%2FXS-Labs-Style-Guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/macmade%2FXS-Labs-Style-Guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/macmade%2FXS-Labs-Style-Guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/macmade","download_url":"https://codeload.github.com/macmade/XS-Labs-Style-Guide/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249701599,"owners_count":21312757,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["assembly","c","c-plus-plus","code","coding-standards","coding-style","conventions","csharp","guide","objective-c","reference","swift"],"created_at":"2024-12-12T05:12:55.300Z","updated_at":"2025-04-19T13:13:12.523Z","avatar_url":"https://github.com/macmade.png","language":null,"funding_links":["https://github.com/sponsors/macmade"],"categories":[],"sub_categories":[],"readme":"XS-Labs Coding Style Guide\n==========================\n\n[![Issues](http://img.shields.io/github/issues/macmade/XS-Labs-Style-Guide.svg?logo=github)](https://github.com/macmade/XS-Labs-Style-Guide/issues)\n![Status](https://img.shields.io/badge/status-active-brightgreen.svg?logo=git)\n![License](https://img.shields.io/badge/license-bsd-brightgreen.svg?logo=open-source-initiative)  \n[![Contact](https://img.shields.io/badge/follow-@macmade-blue.svg?logo=twitter\u0026style=social)](https://twitter.com/macmade)\n[![Sponsor](https://img.shields.io/badge/sponsor-macmade-pink.svg?logo=github-sponsors\u0026style=social)](https://github.com/sponsors/macmade)\n\nTable Of Contents\n-----------------\n\n 1. [About](#about)\n 2. [License](#license)\n 3. [Git Commit Style Guide](#git)\n 4. [C Style Guide](#c)\n 5. [C++ Style Guide](#cpp)\n 6. [Swift Style Guide](#swift)\n 7. [C# Style Guide](#csharp)\n 8. [Objective-C Style Guide](#objc)\n 9. [x86 Assembly Style Guide](#asm)\n\n\u003ca name=\"about\"\u003e\u003c/a\u003e\nAbout\n-----\n\nThese are the coding conventions used for all recent [XS-Labs](http://www.xs-labs.com/) projects.  \nFeel free to comment, raise issues, fork and/or adapt this document.\n\n### Note about whitespaces\n\nXS-Labs' coding conventions make a heavy use of whitespaces.  \nIt's not a common habit among coders, who usually prefers compact code.\n\nThis is just a personal taste.  \nAfter years of professional development, I like to see a lot of spaces in my own code. It's like letting the code breath.   \nCode is about rhythm, and readability. And I think taking time to carefully align operators, declarations, etc. improves the overall readability and the feeling you can get while reading code.\n\n\u003ca name=\"license\"\u003e\u003c/a\u003e\nLicense\n-------\n\nThis style guide is published under the terms of the [FreeBSD documentation license](http://www.freebsd.org/copyright/freebsd-doc-license.html).\n\n\u003ca name=\"git\"\u003e\u003c/a\u003e\nGit Commit Style Guide\n----------------------\n\nAlways follow the Conventional Commits specification for Git commit messages:  \nhttps://www.conventionalcommits.org/en/v1.0.0/\n\nAllowed commit types are:\n\n - `fix`\n - `feat`\n - `chore`\n - `style`\n - `refactor`\n - `build`\n - `test`\n - `ci`\n - `revert`\n\n\u003ca name=\"c\"\u003e\u003c/a\u003e\nC Style Guide\n-------------\n\n  1.  [Indentation](#c-1)\n  2.  [Ending line](#c-2)\n  3.  [Comments](#c-3)\n  4.  [Maximum number of columns](#c-4)\n  5.  [Includes](#c-5)\n  6.  [Whitespace](#c-6)\n      1. [Operators](#c-6-1)\n      2. [Parenthesis and brackets](#c-6-2)\n      3. [Pointers](#c-6-2)\n      4. [Casts](#c-6-4)\n      5. [`for` loops](#c-6-5)\n  7.  [Braces](#c-7)\n  8.  [Alignment](#c-8)\n      1. [Assignments](#c-8-1)\n      2. [Variable declarations](#c-8-2)\n      3. [Single line conditionals](#c-8-3)\n      4. [Array subscripting operator](#c-8-4)\n  9.  [Case and symbols naming](#c-9)\n  10. [Variable declaration](#c-10)\n  11. [Macros](#c-111)\n  12. [Structures and unions](#c-12)\n  13. [Enumerated types](#c-13)\n  14. [Typedefs](#c-14)\n  15. [New lines](#c-14)\n  16. [Header guards](#c-16)\n  17. [Functions prototypes](#c-17)\n  18. [Functions with no parameters](#c-18)\n  19. [Inline functions](#c-19)\n  20. [Dereferencing](#c-20)\n  21. [Conditionals](#c-21)\n  22. [Switch statements](#c-22)\n  23. [Long `if/else if` statements](#c-23)\n  24. [C++ compatibility](#c-24)\n  25. [Inline documentation](#c-25)\n  26. [Compilation](#c-26)\n\n\u003ca name=\"c-1\"\u003e\u003c/a\u003e\n### 1. Indentation\n\nCode should always be indented using four spaces.  Never use tabulations for indentation.\n\nPreprocessor directives should also be indented:\n\n```C\nvoid foo( void )\n{\n    #ifdef FOO\n    /* ... */\n    #endif\n}\n```\n\nNot:\n\n```C\nvoid foo( void )\n{\n#ifdef FOO\n    /* ... */\n#endif\n}\n```\n\n\u003ca name=\"c-2\"\u003e\u003c/a\u003e\n### 2. Ending line\n\nSource and header files should always end with a single empty line.\n\n\u003ca name=\"c-3\"\u003e\u003c/a\u003e\n### 3. Comments\n\nComments should always use the `/* */` notation.  \nSingle line C++ style comments (`//`) are strictly prohibited.\n\nA line of comment should whenever possible be no more that 80 columns.\n\nWhen a comment consists of a single line, place the `/* */` on the same line.  \nIf the comments consists of multiple lines, place the `/* */` on a new line:\n\n```C\n/* Single line comment */\n\n/*\n * Multiple\n * line\n * comment\n */\n```\n\nWhen using multiple line comments, always align the `*` signs, as in the above example.\n\n\u003ca name=\"c-4\"\u003e\u003c/a\u003e\n### 4. Maximum number of columns\n\nThe number of columns for a single line is not limited.  \nHowever, try whenever possible to wrap long lines in order to improve the overall readability.\n\n\u003ca name=\"c-5\"\u003e\u003c/a\u003e\n### 5. Includes\n\nInclude directives should always come first, before any other declaration:\n\n```C\n#include \u003cstdio.h\u003e\n\nint x;\n```\n\nNot:\n\n```C\nint x;\n\n#include \u003cstdio.h\u003e\n```\n\nAn exception is made when a header needs a specific macro to be set before inclusion:\n\n```C\n#define FOOBAR 1 /* Permitted */\n\n#include \u003cfoobar.h\u003e\n```\n\n\u003ca name=\"c-6\"\u003e\u003c/a\u003e\n### 6. Whitespace\n\n\u003ca name=\"c-6-1\"\u003e\u003c/a\u003e\n#### 6.1 Operators\n\nA single whitespace character should always be used around all operators except unary operators:\n\n```C\nx = 1 + 2 + 3;\n\nx++;\n~x;\n\nif( !x )\n{\n    /* .... */\n}\n```\n\nNot:\n\n```C\nx=1+2+3;\n\nx ++;\n~ x;\n\nif( ! x )\n{\n    /* .... */\n}\n```\n\n\u003ca name=\"c-6-2\"\u003e\u003c/a\u003e\n#### 6.2 Parenthesis and brackets\n\nA single whitespace character should always be used inside parenthesis and brackets, but never before:\n\n```C\nx[ 0 ] = 0;\n\nfoo( x );\n\nif( y == 0 )\n{\n    /*  */\n}\n```\n\nNot:\n\n```C\nx[0] = 0;\n\nfoo (x);\n\nif (y == 0)\n{\n    /*  */\n}\n```\n\n\u003ca name=\"c-6-3\"\u003e\u003c/a\u003e\n#### 6.3 Pointers\n\nThe pointer sign should alway have a leading and trailing space:\n\n```C\nint * x;\n```\n\nNot:\n\n```C\nint* x;\nint *x;\n```\n\n\u003ca name=\"c-6-4\"\u003e\u003c/a\u003e\n#### 6.4 Casts\n\nNo whitespace should be added after a cast. A single whitespace should be used after the opening parenthesis and before the closing one:\n\n```C\nx = ( char * )y;\n```\n\nNot:\n\n```C\nx = ( char * ) y;\n```\n\n\u003ca name=\"c-6-5\"\u003e\u003c/a\u003e\n#### 6.5 `for` loops\n\nWhen using `for` loops, a single whitespace character should be used after the semicolons:\n\n```C\nfor( i = 0; i \u003c 10; i++ )\n{\n    /* ... */\n}\n```\n\nNot:\n\n```C\nfor( i = 0;i \u003c 10;i++ )\n{\n    /* ... */\n}\n```\n\n\u003ca name=\"c-7\"\u003e\u003c/a\u003e\n### 7. Braces\n\nBraces should always be placed on an empty line.  \nThis apply for all constructs (functions, conditions, loops, etc.).  \nCode inside braces should be indented by four spaces:\n\n```C\nvoid foo( void )\n{\n    if( ... )\n    {\n    \t/* ... */\n    }\n    else if( ... )\n    {\n    \t/* ... */\n    }\n    else\n    {\n    \t/* ... */\n    }\n    \n    for( ... )\n    {\n    \t/* ... */\n    }\n    \n    while( ... )\n    {\n    \t/* ... */\n    }\n    \n    do\n    {\n    \t/* ... */\n    }\n    while( ... );\n}\n```\n\nAn exceptions can be made for very simple constructs:\n\n```C\n     if( ... ) { x = 1; }\nelse if( ... ) { x = 2; }\n```\n\n\u003ca name=\"c-8\"\u003e\u003c/a\u003e\n### 8. Alignment\n\n\u003ca name=\"c-8-1\"\u003e\u003c/a\u003e\n#### 8.1 Assignments\n\nAlways align consecutive assignments:\n\n```C\nx       = 1;\nfoo     = 2;\nfoobar += 2;\n```\n\nNot:\n\n```C\nx = 1;\nfoo = 2;\nfoobar += 2;\n```\n\nIf using multiple lines in an assignment, aligns the extra lines to the equal sign:\n\n```C\nx      = 1;\nfoobar = x\n       + 1\n       + 2;\n```\n\nWhen using conditional assignment, aligns the `?` and `:` signs whenever possible.  \nThe `?` sign should be aligned by adding whitespaces before the closing parenthesis:\n\n```C\nx      = 1;\nfoobar = ( x      ) ? 2      : x + 3;\nfoo    = ( foobar ) ? foobar : x;\n```\n\nNot:\n\n```C\nx      = 1;\nfoobar = ( x ) ? 2 : x + 3;\nfoo    = ( foobar ) ? foobar : x;\n```\n\n\u003ca name=\"c-8-2\"\u003e\u003c/a\u003e\n#### 8.2. Variable declarations\n\nAlways aligns the names of variables:\n\n```C\nint           x;\nunsigned long y;\nfloat         z;\n```\n\nNot:\n\n```C\nint x;\nunsigned long y;\nfloat z;\n```\n\nWhen using pointers, place the pointer sign next to the variable name:\n\n```C\nint           * x;\nunsigned long * y;\n```\n\n\u003ca name=\"c-8-3\"\u003e\u003c/a\u003e\n#### 8.3. Single line conditionals\n\nIf using single line conditional statements (see above), align the `if`/`else` statements, as well as the opening/closing braces and comparison operators:\n\n```C\n     if( x      == 1 ) { foobar = 1;          }\nelse if( foobar == 1 ) { x      = 0xFFFFFFFF; }\nelse                   { x      = 0;          }\n```\n\nNot:\n\n```C\nif( x == 1 ) { foobar = 1; }\nelse if( foobar == 1 ) { x = 0xFFFFFFFF; }\nelse { x = 0; }\n```\n\n\u003ca name=\"c-8-4\"\u003e\u003c/a\u003e\n#### 8.4. Array subscripting operator\n\nAlways align the closing brackets when using the array subscripting operator. Indexes should be indented in a logical manner:\n\n```C\nx[   1 ] = 0;\nx[ 100 ] = 0;\n```\n\nNot:\n\n```C\nx[ 1 ]   = 0;\nx[ 100 ] = 0;\n```\n\n\u003ca name=\"c-9\"\u003e\u003c/a\u003e\n### 9. Case and symbols naming\n\nLocal variables should never start with an underscore, and should always start with a lowercase letter.  \nLower camel-case is recommended.\n\nFor global symbols (variables and functions), upper camel-case is usually recommended.  \nUnderscores may be used to simulate namespaces.\n\n```C\nvoid SomePackage_SomePublicFunction( void );\n\nextern int SomeInteger;\n```\n\nSymbols shall never start with two underscores, or with an underscore followed by an uppercase letter.\n\n\u003ca name=\"c-10\"\u003e\u003c/a\u003e\n### 10. Variable declaration\n\nLocal variables should be declared before any other statement:\n\n```C\nvoid foo( void )\n{\n    int x = 0;\n    int y = 1;\n    \n    foo();\n    foobar();\n}\n```\n\nNot:\n\n```C\nvoid foo( void )\n{\n    bar();\n    \n    int x = 0;\n    \n    foobar();\n    \n    int y = 0;\n}\n```\n\nIf you need to delcare variables after a statement, always use a dedicated scope:\n\n```C\nvoid foo( void )\n{\n    int x = 0;\n    \n    foo();\n\n    {\n        int y = 1;\n        \n        foobar();\n    }\n}\n```\n\nThe rules above do not apply to `for` loops, where a variable delcaration is permitted and recommended:\n\n```C\nfor( int i = 0; i \u003c 10; i++ )\n{\n    /* ... */\n}\n```\n\nNot:\n\n```C\nint i;\n\nfor( i = 0; i \u003c 10; i++ )\n{\n    /* ... */\n}\n```\n\n\u003ca name=\"c-11\"\u003e\u003c/a\u003e\n### 11. Macros\n\nMacros should always be in uppercase.\n\n```C\n#define FOO         1\n```\n\nIf a macro takes parameters, the parameters names should begin and end with a single underscore:\n\n```C\n#define BAR( _x_ )  ( ( _x_ ) + 1 )\n```\n\nAs in the above example, parenthesis should always be used around a macro parameter.\n\n\u003ca name=\"c-12\"\u003e\u003c/a\u003e\n### 12. Structures and unions\n\nMembers of structures and unions should be properly aligned, as mentioned before:\n\n```C\nstruct foo\n{\n\tint           x;\n\tunsigned long y;\n};\n\nunion bar\n{\n\tint           x;\n\tunsigned long y;\n};\n```\n\nWhen manually padding a struct, use a leading underscore for the member name, and a trailing number, prefixed with a single underscore.  \nAlways use a `char` array to manually pad a structure:\n\n```C\nstruct foo\n{\n\tchar s;\n\tchar _pad_0[ 3 ];\n\tint  x;\n};\n```\n\n\u003ca name=\"c-13\"\u003e\u003c/a\u003e\n### 13. Enumerated types\n\nEnum values should be properly aligned, as mentioned before.  \nIf using explicit values, hexadecimal notation is preferred:\n\n```C\nenum\n{\n    Foo    = 0x01,\n    Bar    = 0x02,\n    Foobar = 0x10\n};\n```\n\nNot:\n\n```C\nenum\n{\n    Foo,\n    Bar,\n    Foobar = 0x10\n};\n```\n\nWhen using flags, the left shift operator is recommended:\n\n\n```C\nenum\n{\n    Foo    = 1 \u003c\u003c 0,\n    Bar    = 1 \u003c\u003c 1,\n    Foobar = 1 \u003c\u003c 2\n};\n```\n\n\n\u003ca name=\"c-14\"\u003e\u003c/a\u003e\n### 14. Typedefs\n\nSimple typedefs are declared on a single line:\n\n```C\ntypedef int Foo;\n```\n\nWith structures, unions and enumrated types place the type name on a new line:\n\n```C\ntypedef struct\n{\n    int x;\n    int y;\n}\nFoo;\n```\n\nFor enumrated types, each value should be prefixed by the type name:\n\n```C\ntypedef enum\n{\n    FooX = 0,\n    FooY = 1,\n    FooZ = 2\n}\nFoo;\n```\n\nNot:\n\n```C\ntypedef enum\n{\n    X = 0,\n    Y = 1,\n    Z = 2\n}\nFoo;\n```\n\n\u003ca name=\"c-15\"\u003e\u003c/a\u003e\n### 15. New lines\n\nAn empty line should be used to separate logical parts of the code, as well as to separate function calls and assignments:\n\n```C\nx = 0;\ny = 0;\n\nfoo();\n\nz = 2;\n```\n\nNot:\n\n```C\nx = 0;\ny = 0;\nfoo();\ny = 2;\n```\n\n\u003ca name=\"c-16\"\u003e\u003c/a\u003e\n### 16. Header guards\n\nAll headers should be properly guarded:\n\n```C\n#ifndef FOO_H\n#define FOO_H\n\n/* ... */\n\n#endif /* FOO_H */\n```\n\nThe name of the macro used as header guard should always be in uppercase.  \nIt should consist of the name of the header file (optionally with directories prefixes, separated by a single underscore), and a trailing `_H`.\n\nFor instance, for `include/foo/bar/foobar.h`, this should be `FOO_BAR_FOOBAR_H`.\n\n\u003ca name=\"c-17\"\u003e\u003c/a\u003e\n### 17. Functions prototypes\n\nFunction prototypes should always declare the parameters names.  \nA single whitespace character should be used after the coma separating parameters.  \nThe return type should be place on the same line as the function's name:\n\n```C\nvoid foo( int x, int y );\n```\n\nNot:\n\n```C\nvoid\nfoo( int,int );\n```\n\n\u003ca name=\"c-18\"\u003e\u003c/a\u003e\n### 18. Functions with no parameters\n\nFunctions without parameters should always be declared as taking `void`:\n\n```C\nvoid foo( void );\n```\n\nNot:\n\n```C\nvoid foo();\n```\n\n\u003ca name=\"c-19\"\u003e\u003c/a\u003e\n### 19. Inline functions\n\nInline functions should generally be avoided, unless there's a very good and specific reason to make them inline.\n\n\u003ca name=\"c-20\"\u003e\u003c/a\u003e\n### 20. Dereferencing\n\nWhen using the dereference operator `*`, always use an extra set of parenthesis:\n\n```C\n*( x ) = 1;\ny      = *( x );\n```\n\nNot:\n\n```C\n*x = 1;\ny  = *x;\n```\n\n\u003ca name=\"c-21\"\u003e\u003c/a\u003e\n### 21. Conditionals\n\nAlways use braces with conditionals:\n\n```C\nif( x == 1 )\n{\n    x = 2;\n}\n```\n\nNot:\n\n```C\nif( x == 1 )\n    x = 2;\n```\n\nDon't use `else` clauses when not necessary:\n\n```C\nif( x == 0 )\n{\n    return true;\n}\n\nreturn false;\n```\n\nNot:\n\n```C\nif( x == 0 )\n{\n    return true;\n}\nelse\n{\n    return false;\n}\n```\n\nAlso avoid using `!` in a conditional:\n\n```C\nif( b == false || p == null )\n{\n    /* ... */\n}\n```\n\nNot:\n\n```C\nif( !b || !p )\n{\n    /* ... */\n}\n```\n\n\u003ca name=\"c-22\"\u003e\u003c/a\u003e\n### 22. Switch statements\n\nWhen using switch statements, separate each `case` with an empty line and adds an empty line after the `case`.  \nThe `break` statement should be indented, in regard to the `case` statement.\n\n```C\nswitch( x )\n{\n    case 1:\n        \n        /* ... */\n        break;\n        \n    default:\n        \n        /* ... */\n        break;\n}\n```\n\nAn exception can be made for very simple switch statements:\n\n```C\nswitch( x )\n{\n    case 1:  y      = 0;          break;\n    default: foobar = 0xFFFFFFFF; break;\n}\n```\n\nIn such a case, `break` statements should be aligned, as well as assignment operators, if any.\n\n\u003ca name=\"c-23\"\u003e\u003c/a\u003e\n### 23. Long `if`/`else if` statements\n\nVery long `if`/`else if` statements should be wrapped the following way:\n\n```C\nif\n(\n       x      == 1\n    \u0026\u0026 y      == 2\n    \u0026\u0026 foobar == 3\n)\n{\n   /* ... */\n}\n```\n\nParenthesis are placed on a new line. Variable names and comparison operators should be aligned.\n\nWhen using extra parenthesis, apply the same rules:\n\n```C\nif\n(\n       x == 1\n    \u0026\u0026 y == 2\n    \u0026\u0026\n    (\n          z      == 3\n       || foobar == 4\n    )\n)\n{\n   /* ... */\n}\n```\n\n\u003ca name=\"c-24\"\u003e\u003c/a\u003e\n### 24. C++ compatibility\n\nAll headers should be compatible with C++, using `extern \"C\"`:\n\n```C\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n\n/* ... */\n\n#ifdef __cplusplus\n}\n#endif\n```\n\n\u003ca name=\"c-254\"\u003e\u003c/a\u003e\n### 25. Inline documentation\n\nDocumented code should prefer [Apple's HeaderDoc](https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/HeaderDoc/intro/intro.html) syntax rather than JavaDoc.\n\n\u003ca name=\"c-26\"\u003e\u003c/a\u003e\n### 26. Compilation\n\nAlways compiles your code with `-Werror` or similar, and always use the highest possible error reporting level.\n\nWhen function parameters are not used, cast them to `void` to prevent a warning:\n\n```C\nvoid foo( int unused )\n{\n    ( void )unused;\n}\n```\n\n\u003ca name=\"cpp\"\u003e\u003c/a\u003e\nC++ Style Guide\n---------------\n\n**All rules from the C Style Guide applies here, with a few exceptions and additions described hereafter.**\n\n  1.  [Files and files extensions](#cpp-1)\n  2.  [Comments](#cpp-2)\n  3.  [Namespaces](#cpp-3)\n  4.  [Classes](#cpp-4)\n     1. [Naming](#cpp-4-1)\n     2. [Inheritance](#cpp-4-2)\n     3. [Members](#cpp-4-3)\n     4. [Method definitions](#cpp-4-4)\n     5. [Destructors](#cpp-4-5)\n  5.  [Templates](#cpp-5)\n  6.  [Using](#cpp-6)\n  7.  [Variable declaration](#cpp-7)\n  8.  [Function/method arguments](#cpp-8)\n  9.  [Functions with no parameters](#cpp-9)\n  10. [Lambdas](#cpp-10)\n  11. [Enumerated types](#cpp-11)\n  12. [Includes and forward declarations](#cpp-12)\n  13. [Using C functions](#cpp-13)\n\n\u003ca name=\"cpp-1\"\u003e\u003c/a\u003e\n### 1. Files and files extensions\n\nC++ source files should end with the `.cpp` extension.  \nC++ headers should end with the `.hpp` extension.\n\nSource and header files for classes should be named as the classes they declare/define.  \nNamespaces should be represented as directories.\n\n\u003ca name=\"cpp-2\"\u003e\u003c/a\u003e\n### 2. Comments\n\nSingle line C++ comments are allowed, even if the `/*  */` notation is usually preferred, especially when the comment consists of multiple lines.\n\n\u003ca name=\"cpp-3\"\u003e\u003c/a\u003e\n### 3. Namespaces\n\nNamespaces should always follow the upper camel-case rule.\n\n\u003ca name=\"cpp-4\"\u003e\u003c/a\u003e\n### 4. Classes\n\n\u003ca name=\"cpp-4-1\"\u003e\u003c/a\u003e\n#### 4.1. Naming\n\nC++ classes should always follow the upper camel-case rule.  \nProperties should always follow the lower camel-case rule.  \nMethods should follow either the upper camel-case rule or the lower camel-case rule, but mixing both in the same project is not allowed.\n\nPrivate members should always have a leading underscore.\n\n\u003ca name=\"cpp-4-2\"\u003e\u003c/a\u003e\n#### 4.2. Inheritance\n\nThe `:` sign should immediately follow the class name and should be followed by a single whitespace character.  \nWhen inheriting from multiple classes, a single whitespace character should be used after the comma:\n\n```C++\nclass FooBar: Foo, Bar\n{\n\t\n};\n```\n\n\u003ca name=\"cpp-4-3\"\u003e\u003c/a\u003e\n#### 4.3. Members\n\nPublic members should be declared first, followed by protected and private members.  \nAlways group members with the same visibility (properties and methods), unless it is not possible.  \n\nStatic members should also be declared first, inside the visibility group, followed by methods and properties.  \nSeparate static methods, methods and properties by an empty line.\n\nThe `public`, `protected` and `private` keywords should be indented by four spaces and an empty line should be placed directly after.  \nMembers should be indented by four more spaces:\n\n```C++\nclass Foo\n{\n    public:\n        \n        static void staticMethod();\n        \n        Foo();\n        \n        int           x;\n        unsigned long y;\n        \n    private:\n        \n        void _bar();\n        \n        int _z;\n};\n```\n\n\u003ca name=\"cpp-4-4\"\u003e\u003c/a\u003e\n#### 4.4. Method definitions\n\nExcept for templates, method should never be defined in the header files.\n\n\u003ca name=\"cpp-4-5\"\u003e\u003c/a\u003e\n#### 4.5. Destructors\n\nDestructors should always be declared as `virtual`, unless there's a very good and specific reason not to do so.\n\n\u003ca name=\"cpp-5\"\u003e\u003c/a\u003e\n### 5. Templates\n\nTemplate parameters should be surrounded by a single whitespace character.  \nA single whitespace character should be used after the comma.  \nThe `\u003c` sign should immediately follow the class name:\n\n```C++\ntemplate class Foo\u003c int x, int y \u003e\n{\n    \n};\n```\n\n\u003ca name=\"cpp-6\"\u003e\u003c/a\u003e\n### 6. Using\n\nThe `using` keyword is usually discouraged for namespaces, except for very long namespaces.  \nIt's strictly prohibited for the `std` namespace - the full notation should always be used.\n\n```C++\nstd::vector\u003c int \u003e v;\n```\n\nNot:\n\n```C++\nusing std;\n\nvector\u003c int \u003e v;\n```\n\n\u003ca name=\"cpp-7\"\u003e\u003c/a\u003e\n### 7. Variable declaration\n\nAlways declare variables with a value.  \nUse either parenthesis or the equal sign.  \n\n```C++\nint x( 0 );\n```\n\nOr:\n\n```C++\nint x = 0;\n```\n\nUsing braces is also allowed.  \nIn such a case, always add a leading space before the opening brace:\n\n```C++\nint x {};\nint y { 42 };\n```\n\nNot:\n\n```C++\nint x{};\nint y{ 42 };\n```\n\nVariables declarations and statement may be mixed in C++.  \nIn such a case, always separate variables declarations and statements with an empty line:\n\n```C++\nint x = 0;\n\nFoo::Bar();\n\nstd::string s = \"hello, world\";\n```\n\n\n\u003ca name=\"cpp-8\"\u003e\u003c/a\u003e\n### 8. Function/method arguments\n\nExcept for out parameters, primitive or integral types should always be passed by value.  \nFor other types, passing `const` references is preferred:\n\n```C++\nvoid foo( int value );\nvoid bar( const std::string \u0026 value );\n```\n\nOver:\n\n```C++\nvoid foo( const int \u0026 value );\nvoid bar( std::string value );\n```\n\n\u003ca name=\"cpp-9\"\u003e\u003c/a\u003e\n### 9. Functions with no parameters\n\nUnlike C conventions, empty parenthesis are fine and preferred for functions or methods without parameters:\n\n```C++\n    void foo();\n```\n\n\u003ca name=\"cpp-10\"\u003e\u003c/a\u003e\n### 10. Lambdas\n\nWhen using lambdas, a single space should be placed before and after any capture.  \nA single space should be placed after the comma in the capture list.  \nWhen there is no capture, no space should be placed inside the brackets:\n\n```C++\nauto a = []()            {};\nauto b = [ \u0026 ]()         {};\nauto c = [ this ]()      {};\nauto c = [ this, foo ]() {};\n```\n\nNot:\n\n```C++\nauto a = [ ]()        {};\nauto b = [\u0026]()        {};\nauto c = [this]()     {};\nauto c = [this,foo]() {};\n```\n\nNo space should be placed between the capture brackets and the opening parenthesis for arguments.\n\n```C++\nauto a = []( int x ) {};\nauto b = []()        {};\n```\n\nNot:\n\n```C++\nauto a = [] (int x) {};\nauto b = []         {};\n```\n\nThe return type may be omitted.  \nIf specified, a leading and trailing space should be placed around `-\u003e`:\n\n```C++\nauto a = []() -\u003e int {};\n```\n\nNot:\n\n```C++\nauto a = []()-\u003eint {};\n```\n\n\u003ca name=\"cpp-11\"\u003e\u003c/a\u003e\n### 11. Enumerated types\n\nScoped enumerations should always be preferred over unscoped enumerations:\n\n```C++\nenum class Foo\n{\n    X\n    Y\n};\n```\n\nOver:\n\n```C++\nenum Foo\n{\n    FooX\n    FooY\n};\n```\n\n\u003ca name=\"cpp-12\"\u003e\u003c/a\u003e\n### 12. Includes and forward declarations\n\nThe number of included files contained in the headers should be limited.  \nAlways use forward declarations when possible:\n\n```C++\nclass Foo;\n\nclass Bar\n{\n    public:\n        \n        Bar( Foo * f );\n};\n```\n\nNot:\n\n```C++\n#include \"Foo.h\"\n\nclass Bar\n{\n    public:\n        \n        Bar( Foo * f );\n};\n```\n\n\u003ca name=\"cpp-13\"\u003e\u003c/a\u003e\n### 13. Using C functions\n\nThe use of C functions is generally discouraged unless there's no C++ equivalent, or if there's a specific reason not to use a C++ equivalent.\n\nC library headers should not be used directly. Always use the C++ variants instead, when available:\n\n```C++\n#include \u003ccstdio\u003e\n```\n\nNot:\n\n```C++\n#include \u003cstdio.h\u003e\n```\n\n\u003ca name=\"swift\"\u003e\u003c/a\u003e\nSwift Style Guide\n-----------------\n\n... Work in progress ...\n\n\u003ca name=\"csharp\"\u003e\u003c/a\u003e\nC# Style Guide\n--------------\n\n... Work in progress ...\n\n\u003ca name=\"objc\"\u003e\u003c/a\u003e\nObjective-C Style Guide\n-----------------------\n\n**All rules from the C Style Guide applies here, with a few exceptions and additions described hereafter.**\n\n  1.  [Files](#objc-1)\n  2.  [Primitive datatypes](#objc-2)\n  3.  [Bracket notation](#objc-3)\n  4.  [Literals](#objc-4)\n  5.  [Constants](#objc-5)\n  6.  [Enumerated types](#objc-6)\n  7.  [`NULL`, `nil` and `Nil`](#objc-7)\n  8.  [Blocks](#objc-8)\n  9.  [Classes](#objc-9)\n      1.  [Naming](#objc-9-1)\n      2.  [Interface declaration](#objc-9-2)\n      3.  [Instance variables](#objc-9-3)\n      4.  [Properties](#objc-9-4)\n      5.  [Properties atomicity](#objc-9-5)\n      6.  [Methods](#objc-9-6)\n      7.  [Imports and forward declarations](#objc-9-7)\n      8.  [Private methods](#objc-9-8)\n      9.  [Categories](#objc-9-9)\n      10. [Protocols](#objc-9-10)\n  10. [Singletons/Shared instances](#objc-10)\n  11. [NSLog](#objc-11)\n  12. [Multithreading](#objc-12)\n  13. [Compilation](#objc-13)\n\n\u003ca name=\"objc-1\"\u003e\u003c/a\u003e\n### 1. Files\n\nSource and header files for classes should be named as the classes they declare/define.  \nDirectories should be used to separate logical groups of source files.\n\nFor categories, the source and header files should be name as the class, followed by a `+` and the category name (`SomeClass+SomeCategory.m`).\n\n\u003ca name=\"objc-2\"\u003e\u003c/a\u003e\n### 2. Primitive datatypes\n\nUnless there's a specific need to do so, never use the C primitive datatypes.  \nThe Objective-C equivalent should always be preferred:\n\n  * `NSInteger` instead of `int` or `long`\n  * `NSUInteger` instead of `unsigned int` or `unsigned long`\n  * `CGFloat` instead of `float` or `double`\n\nOr use the types from `stdint.h` when needed.\n\n\u003ca name=\"objc-3\"\u003e\u003c/a\u003e\n### 3. Bracket notation\n\nWhen sending messages, a single whitespace should be used before and after the brackets:\n\n```Objective-C\na = [ [ NSArray alloc ] init ];\n```\n\nNot:\n\n```Objective-C\na = [[NSArray alloc]init];\n```\n\nLong lines should be wrapped the following way:\n\n```Objective-C\na = [ [ NSDictionary alloc ] initWithObjects: obj1,\n                                              obj2,\n                                              obj3,\n                                              nil\n                             forKeys:         @\"key1\",\n                                              @\"key2\",\n                                              @\"key3\",\n                                              nil\n    ];\n```\n\nThe closing bracket is aligned with the opening one.  \nParts of the method name are aligned to the left, as well as arguments.\n\n\u003ca name=\"objc-5\"\u003e\u003c/a\u003e\n### 5. Literals\n\nThe use of literals is generally encouraged, as well as subscripting:\n\n```Objective-C\narray      = @[ obj1, obj2 ];\ndictionary = @{ @\"key1\" : obj1, @\"key2\" : obj2 };\nnumber     = @42;\n```\n\nInstead of:\n\n```Objective-C\narray      = [ NSArray arrayWithObjects: obj1, obj2, nil ];\ndictionary = [ NSDictionary dictionaryWithObjectsAndKeys: obj1, @\"key1\", obj2, @\"key2\", nil ];\nnumber     = [ NSNumber numberWithInteger: 42 ];\n```\n\nLong declarations for array or dictionaries literals should be wrapped the following way:\n\n```Objective-C\narray      = @[\n                  obj1,\n                  obj2\n              ];\ndictionary = @{\n                  @\"key1\"   : obj1,\n                  @\"key2\"   : obj2,\n                  @\"foobar\" : obj2\n              };\n```\n\nThe opening and closing brackets/braces are aligned.  \nContained objects are placed on their own line, indented by four spaces.\n\nFo dictionaries, the `:` signs are aligned.\n\n\u003ca name=\"objc-6\"\u003e\u003c/a\u003e\n### 6. Constants\n\nThe use of the `k` prefix for constants is prohibited.  \nWhen related to a class, constants should be prefixed by the class name.\n\nThe name of constants should follow the upper camel-case rule.\n\nThe use of the `extern` keyword is strictly prohibited for constants. Use the `FOUNDATION_EXPORT` macro instead:\n\n```Objective-C\nFOUNDATION_EXPORT NSString * const SomeClassConstantName;\n```\n\nNot\n\n```Objective-C\nextern NSString * const kConstantName;\n```\n\n\u003ca name=\"objc-7\"\u003e\u003c/a\u003e\n### 7. Enumerated types\n\nThe use of the `NSEnum` and `NSOptions` macros is encouraged, while not mandatory.\n\n\u003ca name=\"objc-8\"\u003e\u003c/a\u003e\n### 8. `NULL`, `nil` and `Nil`\n\n`NULL`, `nil` and `Nil` should not be used interchangeably.\n\n`nil` should always be used for instances, while `Nil`should be used for classes.  \nFor any other pointer type, `NULL` should be used.\n\n\u003ca name=\"objc-9\"\u003e\u003c/a\u003e\n### 9. Blocks\n\nThe declaration of a block should follow the same rules as the declaration of a function pointer:\n\n```Objective-C\nNSUInteger ( ^ blockName )( NSUInteger x );\n```\n\nThe `^` sign is surrounded by a single whitespace character.  \nFor complex blocks, a typedef is recommended:\n\n```Objective-C\ntypedef NSUInteger ( ^ blockTypeName )( NSUInteger x );\n```\n\nThe definition of blocks should follow the function's definition style.  \nNo whitespace should be placed after the `^` sign.  \nBlock's code should be indented by four spaces.\n\n```Objective-C\nblock = ^( void )\n{\n    /* ... */\n};\n```\n\nBlocks without arguments should always be defined as taking `void`.\n\n\u003ca name=\"objc-9\"\u003e\u003c/a\u003e\n### 9. Classes\n\n  1.  [Naming](#objc-9-1)\n  2.  [Interface declaration](#objc-9-2)\n  3.  [Instance variables](#objc-9-3)\n  4.  [Properties](#objc-9-4)\n  5.  [Properties atomicity](#objc-9-5)\n  6.  [Methods](#objc-9-6)\n  7.  [Imports and forward declarations](#objc-9-7)\n  8.  [Private methods](#objc-9-8)\n  9.  [Categories](#objc-9-9)\n  10. [Protocols](#objc-9-10)\n\n\u003ca name=\"objc-9-1\"\u003e\u003c/a\u003e\n#### 9.1. Naming\n\nThe name of classes should follow the upper camel-case rule.\n\n\u003ca name=\"objc-9-2\"\u003e\u003c/a\u003e\n#### 9.2. Interface declaration\n\nThe interface declaration should follow the following rules:\n\nInstance variabes are prohibited in the interface (see [9.3. Instance variables](#objc-9-3)).\n\nProperties and methods should not be indented.  \nProperties should come first, followed by methods.\n\nThe `:` sign after the class name should have a trailing whitespace character, but never a leading one.\n\nIf protocols are implemented, the opening `\u003c` sign should have a leading and trailing whitespace character.  \nThe closing `\u003e` sign should have a leading whitespace character.  \nA single whitespace character should be placed after the comma, when implementing multiple protocols.\n\nExample:\n\n```Objective-C\n@interface Foobar: NSObject \u003c Foo, Bar \u003e\n\n@property( atomic, readonly ) NSInteger x;\n\n- ( void )foo;\n\n@end\n```\n\n\u003ca name=\"objc-9-3\"\u003e\u003c/a\u003e\n#### 9.3. Instance variables\n\nInstance variables should follow the lower camel-case rule and start with a single leading underscore.\n\nUsing instance variables should be avoided avoided whenever possible.  \nUse properties instead.\n\nInstance variables are not allowed in the public interface.  \nUse a private class extension in the implementation instead.\n\nExcept when using headerdoc comments, the name of the instance variables should be aligned, as mentioned in the alignment topic of the C style guide:\n\n```Objective-C\n@interface Foo()\n{\n    NSUInteger     _x;\n    NSArray      * _array;\n    NSDictionary * _dict;\n}\n```\n\nNot:\n\n```Objective-C\n@interface Foo()\n{    \n    NSUInteger _x;\n    NSArray * _array;\n    NSDictionary * _dict;\n}\n```\n\n\u003ca name=\"objc-9-4\"\u003e\u003c/a\u003e\n#### 9.4. Properties\n\nProperties variables should follow the lower camel-case rule.\n\nProperties should always declare their full attributes:\n\n```Objective-C\n@property( nonatomic, readwrite, assign ) NSUInteger x;\n```\n\nNot:\n\n```Objective-C\n@property( assign ) NSUInteger x;\n```\n\n\u003ca name=\"objc-9-5\"\u003e\u003c/a\u003e\n#### 9.5. Properties atomicity\n\nProperties should generally be declared as `atomic`, unless there's a specific reason not to do so.\n\nAn exception is made for `IBOutlet` properties, which should always be `nonatomic`.\n\n\u003ca name=\"objc-9-6\"\u003e\u003c/a\u003e\n#### 9.6. Methods\n\nMethods should follow the lower camel-case rule.  \nThe use of a leading underscore is strictly prohibited.\n\nEmpty parameter names are discouraged.\n\nA trailing whitespace should be used after the `+` or `-` sign.  \nThe method's return type and argument's types should follow the same rule as casts, as mentioned in the C style guide.  \nA trailing whitespace character should be used after the `:` sign, but not before:\n\n```Objective-C\n- ( void )methodWithObject1: ( id )object object2: ( id )object;\n```\n\nNot:\n\n```Objective-C\n-( void ) methodWithObject1 :( id ) object object2 :( id ) object;\n```\n\nParameter names should be as explicit as possible.\n\nThe use of a `the` or `a` prefix for a parameter name is strictly prohibited.\n\n```Objective-C\n( id )object\n```\n\nNot:\n\n```Objective-C\n( id )anObject\n```\n\n\u003ca name=\"objc-9-7\"\u003e\u003c/a\u003e\n#### 9.7. Imports and forward declarations\n\nThe number of included files contained in the headers should be limited.  \nAlways use forward declarations when possible:\n\n```Objective-C\n@class Foo;\n\n@interface Bar\n\n- ( id )initWithFoo: ( Foo * )foo;\n\n@end\n```\n\nNot:\n\n```Objective-C\n#import \"Foo.h\"\n\n@interface Bar\n\n- ( id )initWithFoo: ( Foo * )foo;\n\n@end\n```\n\n\u003ca name=\"objc-9-8\"\u003e\u003c/a\u003e\n#### 9.8. Private methods\n\nPrivate methods should be declared and defined in a class extension, in the main implementation.  \nDeclaration may be avoided, but is usually preferred:\n\n```Objective-C\n#import \"Foo.h\"\n\n@interface Foo()\n\n- ( void )bar;\n\n@end\n\n@implementation Foo()\n\n- ( void )bar\n{}\n\n@end\n```\n\n\u003ca name=\"objc-9-9\"\u003e\u003c/a\u003e\n#### 9.9. Categories\n\nEach category should have its own header and source file.  \n\nDeclaration should be as follow, with a single whitespace character around the category name, and no leading whitespace before the `(` sign:\n\n```Objective-C\n@interface Foo( CategoryName )\n```\n\nNot:\n\n```Objective-C\n@interface Foo (CategoryName)\n```\n\n\u003ca name=\"objc-9-10\"\u003e\u003c/a\u003e\n#### 9.10. Protocols\n \nIf the protocol conformance is not intended to be public, the main interface file should not declare it.\n\nFor instance, a `Foo` class implementing `NSTableViewDelegate` (for internal use).\n\n`Foo.h`:\n\n```Objective-C\n@interface Foo: NSObject\n\n@end\n```\n\n`Foo.m`:\n\n```Objective-C\n#import \"Foo.h\"\n\n@interface Foo() \u003c NSTableViewDelegate \u003e\n\n@end\n```\n\n\u003ca name=\"objc-10\"\u003e\u003c/a\u003e\n### 10. Singletons/Shared instances\n\nSingletons or shared instances should always be created with the `dispatch_once` pattern.  \nFor pure singletons, `allocWithZone:` should be overriden to return the shared instance:\n\n```Objective-C\n+ ( instancetype )sharedInstance\n{\n    static dispatch_once_t once;\n    static id              instance = nil;\n    \n    dispatch_once\n    (\n        \u0026once,\n        ^( void )\n        {\n            instance = [ [ super allocWithZone: nil ] init ];\n        }\n    );\n    \n    return instance;\n}\n\n+ ( id )allocWithZone: ( NSZone * )zone\n{\n    ( void )zone;\n    \n    return [ self sharedInstance ];\n}\n```\n\n\u003ca name=\"objc-11\"\u003e\u003c/a\u003e\n### 11. NSLog\n\n`NSLog` should be used carefully.  \nIt's recommended to use a macro to disable logging for release builds.\n\n\u003ca name=\"objc-12\"\u003e\u003c/a\u003e\n### 12. Multithreading\n\nThe use of `libdispatch` should always be preferred to standard `NSThread` approach, unless there's a specific reason to use `NSThread`, like ensuring the thread is detached immediately.\n\n\u003ca name=\"objc-13\"\u003e\u003c/a\u003e\n### 13. Compilation\n\nGCC should never be used to compile Objective-C. Use Clang/LLVM instead.\n\n\u003ca name=\"asm\"\u003e\u003c/a\u003e\nx86 Assembly Style Guide\n------------------------\n\n  1. [Syntax](#asm-1)\n     1. [Direction of Operands](#asm-1-1)\n     2. [Prefixes](#asm-1-2)\n     3. [Suffixes](#asm-1-3)\n     4. [Memory operands](#asm-1-4)\n  2. [Local labels](#asm-2)\n  3. [Indentation](#asm-3)\n  4. [Alignment](#asm-4)\n  5. [Whitespace](#asm-5)\n  6. [Comments](#asm-6)\n  7. [Grouping](#asm-7)\n  8. [Procedures comments](#asm-8)\n  9. [Optimisation](#asm-9)\n     1. [Zeroing](#asm-9-1)\n     2. [Comparing with zero](#asm-9-2)\n     3. [Incrementing and decrementing](#asm-9-3)\n     4. [Branching](#asm-9-4)\n     5. [Loops unrolling](#asm-9-5)\n\n\u003ca name=\"asm-1\"\u003e\u003c/a\u003e\n### 1. Syntax\n\nThe Intel syntax should always be preferred, when possible, to the AT\u0026T syntax, for clarity.  \nAn exception is made for inline assembly, when compiling C code with Clang or GCC.\n\nThe basic differences are the following:\n\n\u003ca name=\"asm-1-1\"\u003e\u003c/a\u003e\n#### 1.1. Direction of Operands\n\nThe direction of the operands in the Intel syntax is the opposite of AT\u0026T syntax.  \nIn the Intel syntax, the destination operand comes first, followed by the source operand:\n\n```NASM\n    instr dest, src  ; Intel\n```\n```GAS\n    instr src,  dest # AT\u0026T\n```\n\n\u003ca name=\"asm-1-2\"\u003e\u003c/a\u003e\n#### 1.2. Prefixes\n\nThe Intel syntax doesn't use prefixes for register names or immediate operands, while the AT\u0026T syntax uses the `%` prefix for registers and `$` for immediate operands:\n\n```NASM\n    mov  rax, 1    ; Intel\n```\n```GAS\n    movq $1,  %rax # AT\u0026T\n```\n\n\u003ca name=\"asm-1-3\"\u003e\u003c/a\u003e\n#### 1.3. Suffixes\n\nThe Intel syntax doesn't use suffixes for mnemonics, while the AT\u0026T syntax uses `b`, `w`, `l` and `q`.  \nThe size of the operands is automatically assumed when using registers.  \nFor memory operands, similar directives can be used (`BYTE`, `WORD`, `DWORD`, `QWORD`):\n\n```NASM\n    ; Intel\n\tmov  rax, 1\n\tmov  eax, 1\n```\n```GAS\n    # AT\u0026T\n\tmovq $1, %rax\n\tmovl $1, %eax\n```\n\n\u003ca name=\"asm-1-4\"\u003e\u003c/a\u003e\n#### 1.4. Memory operands\n\nThe Intel syntax uses `[]` for memory operands, while the AT\u0026T syntax uses `()`:\n```NASM\n    mov  rax, [ rdi + 8 ] ; Intel\n```\n```GAS\n    movq 8( %rdi ), %rax  # AT\u0026T\n```\n\nThe index, scale, displacement and segment also use a different notation:\n\n```NASM\nmov  rax, segment:[ base + index * scale + displacement ] ; Intel\n```\n```GAS\nmovq %segment:displacement( base, index, scale ), %rax    # AT\u0026T\n```\n    \n\u003ca name=\"asm-2\"\u003e\u003c/a\u003e\n### 2. Local labels\n\nLocal labels inside a procedure should always start with a dot.  \nFor instance:\n\n```NASM\nprocedure:\n    \n    .label1:\n        \n        ; ...\n        \n    .label2:\n        \n        ; ...\n        \n    ret\n```\n\nLabel names should be meaningful.  \nDon't use compiler style label names, like `L1:`.\n\n\u003ca name=\"asm-3\"\u003e\u003c/a\u003e\n### 3. Indentation\n\nCode should always be indented using four spaces.  Never use tabulations for indentation.\n\n\u003ca name=\"asm-4\"\u003e\u003c/a\u003e\n### 4. Alignment\n\nMnemonics and operands should be aligned, in order to improve the code's readability, and a decent amount of spaces should be placed between the mnemonics and the operands:\n\n```NASM\nxor      rax,       rax\nmov      al,        1\npxor     xmm0,      xmm0\nmovdqa   xmm1,      [ rsi ]\nmovdqa   [ rdi ],   xmm1\n```\n\nNot this:\n\n```NASM\nxor rax, rax\nmov al, 1\npxor xmm0, xmm0\nmovdqa xmm1, [rsi]\nmovdqa [rdi], xmm1\n```\n\n\u003ca name=\"asm-5\"\u003e\u003c/a\u003e\n### 5. Whitespace\n\nWhen using memory operands, inserts a white space between the brackets:\n\n```NASM\nmov rax, [ rdi ]\n```\n\nNot:\n\n```NASM\nmov rax, [rdi]\n```\n\nAlso inserts a a whitespace around arithmetic operators:\n\n```NASM\nmov rax, [ rdi + 8 ]\n```\n\nNot:\n\n```NASM\nmov rax, [rdi+8]\n```\n\n\u003ca name=\"asm-6\"\u003e\u003c/a\u003e\n### 6. Comments\n\nComments should be placed on a new line and should not exceed 80 columns in width:\n\n```NASM\n; This is a comment\n; with another line...\nxor rax, rax\n```\n\nNot:\n\n```NASM\nxor rax, rax ; This is a comment\n```\n\nComments should be as meaningful as possible.  \nDon't simply describe what you are doing, but also why you are doing it.\n\n\u003ca name=\"asm-7\"\u003e\u003c/a\u003e\n### 7. Grouping\n\nInstructions should be grouped in a logical manner, with a newline between groups:\n\n```NASM\n; Comment for instruction group 1\nxor     rax,     rax\nxor     rcx,     rcx\nmov     al,      2\nmov     cl,      8\nmul     rcx\n\n; Comment for instruction group 2\npxor     xmm0,   xmm0\nmovdqa   xmm1,   [ rdi ]\n```\n\n\u003ca name=\"asm-8\"\u003e\u003c/a\u003e\n### 8. Procedures comments\n\nAll procedures should start with a standard comment, describing the procedure, the input and return registers, as well as killed registers, if any:\n\n```NASM\n;-------------------------------------------------------------------------------\n; Short description of the procedure (single line)\n; \n; Long description of the procedure\n; (can be multi-line)\n; \n; Input registers:\n;       \n;       - RDI:      Parameter description\n;       - RSI:      Parameter description\n; \n; Return registers:\n;       \n;       - RAX:      Return value description\n; \n; Killed registers:\n;       \n;       - RCX\n;       - RDX\n;------------------------------------------------------------------------------- \n```\n\nWhen no register is used as input or as return, or when no register is killed:\n\n```NASM\n;-------------------------------------------------------------------------------\n; Short description of the procedure (single line)\n; \n; Long description of the procedure\n; (can be multi-line)\n;\n; Input registers:\n;       \n;       None\n; \n; Return registers:\n;       \n;       None\n; \n; Killed registers:\n;       \n;       None\n;------------------------------------------------------------------------------- \n```\n\n\u003ca name=\"asm-9\"\u003e\u003c/a\u003e\n### 9. Optimisation\n\nThe following is not mandatory, but it's strongly advised to follow these recommendations, when writing performance-critical code.\n\n\u003ca name=\"asm-9-1\"\u003e\u003c/a\u003e\n#### 9.1. Zeroing\n\nAlways use `xor` to zero a register, instead of `mov`:\n\n```NASM\nxor rax, rax\n```\n    \nNot:\n\n```NASM\nmov rax, 0\n```\n\n\u003ca name=\"asm-9-2\"\u003e\u003c/a\u003e\n#### 9.2. Comparing with zero\n\nAlways use `test` when comparing with zero, instead of `cmp`:\n\n```NASM\ntest rax, rax\njz   .label\n```\n \nNot:\n\n```NASM\ncmp  rax, 0\nje   .label\n```\n\n\u003ca name=\"asm-9-3\"\u003e\u003c/a\u003e\n#### 9.3. Incrementing and decrementing\n\nAlways use `add` and `sub` when incrementing or decrementing a register, instead of `inc` or `dec`:\n\n```NASM\nadd rax, 1\nsub rbx, 1\n```  \n\nNot:\n\n```NASM\ninc rax\ndec rbx\n```\nWhile `inc` and `dec` are shorter, some processors have performance issues with those mnemonics.\n\n\u003ca name=\"asm-9-4\"\u003e\u003c/a\u003e\n#### 9.4. Branching\n\nWhen using conditional jumps, the following rules should be observed in order to increase the overall performances (due to the CPUs branch prediction algorithm).\n\n##### Predict forward conditional branches to be not taken:\n\n```NASM\ntest rax, rax\njz   .label\n\n; Fallthrough - Most likely\n\n.label:\n    \n    ; Forward branch - Most unlikely\n```\n\n##### Predict backward conditional branches to be taken:\n\n```NASM\n.label:\n    \n    ; Backward branch - Most likely\n    \n    test rax, rax\n    jz   .label\n    \n; Fallthrough - Most unlikely\n```\n\nAnd of course, eliminate branches whenever possible.\n\n\u003ca name=\"asm-9-5\"\u003e\u003c/a\u003e\n#### 9.5. Loops unrolling\n\nWhenever possible, unroll loops:\n\n```NASM\n.loop:\n    \n    mov [ rdi      ], [ rsi      ]\n    mov [ rdi +  8 ], [ rsi +  8 ]\n    mov [ rdi + 16 ], [ rsi + 16 ]\n    mov [ rdi + 24 ], [ rsi + 24 ]\n    \n    add  rdi,         32\n    add  rsi,         32\n    sub  rcx,         32\n    \n    test rcx,         rcx\n    jnz .loop\n```\n\nInstead of:\n\n```NASM\n.loop:\n    \n    mov [ rdi ],      [ rsi ]\n    \n    add  rdi,         8\n    add  rsi,         8\n    sub  rcx,         8\n        \n    test rcx,         rcx\n    jnz .loop\n```\n\nRepository Infos\n----------------\n\n    Owner:          Jean-David Gadina - XS-Labs\n    Web:            www.xs-labs.com\n    Blog:           www.noxeos.com\n    Twitter:        @macmade\n    GitHub:         github.com/macmade\n    LinkedIn:       ch.linkedin.com/in/macmade/\n    StackOverflow:  stackoverflow.com/users/182676/macmade\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmacmade%2Fxs-labs-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmacmade%2Fxs-labs-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmacmade%2Fxs-labs-style-guide/lists"}