Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
jami-project
jami-project
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 181
    • Issues 181
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • savoirfairelinux
  • jami-projectjami-project
  • Wiki
    • Guidelines
  • Libringclient Coding Rules

Last edited by Pierre Duchemin Jun 05, 2018
Page history

Libringclient Coding Rules

This page gives rules and/or guidances to all developers that want to integrate some code to the LibRingClient (a Daemon Middleware for Desktop Clients).

  • Following rules apply to this sub-project only. Others may re-use this one in parts or whole, have their own, etc. Refer to their pages for that.
  • Some rules are strict and are strongly marked or using modals like SHALL or MUST.

!!!Not respecting these rules results in code-review rejection!!!

  • Some are guidance or recommendation (using modals like SHOULD or RECOMMEND), it's up to the developer to balance them with his own way to write code.
  • Rules are based on following well known ones, we've modified them for this project:
    • Google C++ CodingStyle for the general C++ domain
    • Qt Coding Conventions and Qt Coding Style as this project use QtCore as framework.
  • This wiki is a permanent Work-In-Progress system. So not all rules are written yet. That doesn't mean we don't have them yet (we = core developer members).
  • We've changed some rules during the project. We update the code iteratively, so tt's extremly possible to find whole files or parts of code that not using these rules.

In such situation, if you need to change only few lines in a "logic" block (i.e. a class declaration, a function body, ...) keep the local rules to make easier the review: we can see what's the important change without being disturbed by coding rules refactoring. If you need such action, use a dedicated patch with a clear mention in the commit message.


Rules

Language Standard

We SHALL use the C++14 standard syntax only.

For gnu-gcc and clang, use compiler command line option -std=c++14 to enforce this rule.

Maximum Line Length

You SHOULD keep your line length under the 120 characters limit.

This limitation is mainly due that integrators used splited view to compare files, and keep it below 120 cols make easier to compare them, even on wide screen. Configure your editing tools to this limit.

If keeping this rule make the code worst to read or non-valid than exceed the limit, the rule can be transgressed. These why we've exceptions to this rule:

  • If a comment line contains an example command or a literal URL longer than 120 characters, that line may be longer than 120 characters for ease of cut and paste.
  • A raw-string literal may have content that exceeds 120 characters. Except for test code, such literals should appear near top of a file.
  • An #include statement with a long path may exceed 120 columns.

Non-ASCII Characters

Non-ASCII characters should be rare, and MUST use UTF-8 formatting.

You SHALL NOT use the C++11 char16_t and char32_t character types, since they're for non-UTF-8 text. For similar reasons you also SHALL NOT use wchar_t (unless you're writing code that interacts with the Windows API, which uses wchar_t extensively).

Spaces vs. Tabs

In code files (i.e. .cpp or .h), you SHALL use spaces to indent.

One indent level is 4 (four) consecutive spaces. You should set your editor to emit spaces when you hit the tab key and when you save your file.

Testing

Each patch for LRC should be accompanied by a test. CppUnit is used to write tests.

Clone repository
  • Choosing CRF value for encoder
  • Deprecated documents
  • Group chat feature (design draft)
  • Home
  • chatview i18n (design draft)
  • features
    • All features by client
  • guidelines
    • Banned Contact
    • Coding rules
    • Identifiers
    • Kde guidelines
    • Libringclient Coding Rules
    • Qt and QML coding guidelines
    • Qt and QML testing tools
    • UI and UX development
  • others
    • gsoc
View All Pages