Libringclient-Coding-Rules.md (3551B)
1 **This page gives rules and/or guidances to all 2 developers that want to integrate some code to the LibRingClient (a 3 Daemon Middleware for Desktop Clients).** 4 5 - Following rules apply to this sub-project only. Others may re-use 6 this one in parts or whole, have their own, etc. Refer to their 7 pages for that. 8 9 <!-- --> 10 11 - Some rules are <u>strict</u> and are **strongly marked** or using 12 modals like SHALL or MUST. 13 14 15 **!!!Not respecting these rules results in code-review rejection!!!** 16 17 - Some are guidance or recommendation (using modals like SHOULD or 18 RECOMMEND), it's up to the developer to balance them with his own 19 way to write code. 20 21 <!-- --> 22 23 - Rules are based on following well known ones, we've modified them 24 for this project: 25 - [Google C++ 26 CodingStyle](https://google.github.io/styleguide/cppguide.html) 27 for the general C++ domain 28 - [Qt Coding Conventions](https://wiki.qt.io/Coding_Conventions) 29 and [Qt Coding Style](https://wiki.qt.io/Qt_Coding_Style) as 30 this project use QtCore as framework. 31 32 <!-- --> 33 34 - This wiki is a permanent Work-In-Progress system. **So not all rules 35 are written yet.** That doesn't mean we don't have them yet (we = 36 core developer members). 37 38 <!-- --> 39 40 - We've changed some rules during the project. We update the code 41 iteratively, so tt's extremly possible to find whole files or parts 42 of code that not using these rules. 43 44 In such situation, if you need to change only few lines in a "logic" 45 block (i.e. a class declaration, a function body, ...) keep the local 46 rules to make easier the review: we can see what's the important change 47 without being disturbed by coding rules refactoring. If you need such 48 action, use a dedicated patch with a clear mention in the commit 49 message. 50 51 --- 52 53 ## Rules 54 55 ### **Language Standard** 56 57 We SHALL use the **C++14 standard** syntax only. 58 59 For gnu-gcc and clang, use compiler command line option `-std=c++14` to 60 enforce this rule. 61 62 ### **Maximum Line Length** 63 64 You SHOULD keep your line length under the **120 characters limit**. 65 66 This limitation is mainly due that integrators used splited view to 67 compare files, and keep it below 120 cols make easier to compare them, 68 even on wide screen. Configure your editing tools to this limit. 69 70 If keeping this rule make the code worst to read or non-valid than 71 exceed the limit, the rule can be transgressed. These why we've 72 **exceptions** to this rule: 73 74 - If a comment line contains an example command or a literal URL 75 longer than 120 characters, that line may be longer than 120 76 characters for ease of cut and paste. 77 - A raw-string literal may have content that exceeds 120 characters. 78 Except for test code, such literals should appear near top of 79 a file. 80 - An \#include statement with a long path may exceed 120 columns. 81 82 ### **Non-ASCII Characters** 83 84 Non-ASCII characters should be rare, and MUST use **UTF-8** formatting. 85 86 You SHALL NOT use the C++11 char16\_t and char32\_t character types, 87 since they're for non-UTF-8 text. For similar reasons you also SHALL NOT 88 use wchar\_t (unless you're writing code that interacts with the Windows 89 API, which uses wchar\_t extensively). 90 91 ### **Spaces vs. Tabs** 92 93 In code files (i.e. .cpp or .h), you SHALL use **spaces to indent**. 94 95 One indent level is 4 (four) consecutive spaces. You should set your 96 editor to emit spaces when you hit the tab key and when you save your 97 file. 98 99 ### **Testing** 100 101 Each patch for LRC should be accompanied by a test. CppUnit is used to 102 write tests.