Page MenuHomeDevCentral

Review and publish C code convention
Open, NormalPublic

Description

Current situation

Currently, our code base largely follow two rules for code style as long as whitespaces are involved:

  • K&R/1BTS, including for method declarations
  • 4 spaces for indent

Python code follows PEP-8 (decision taken at the start of Tasacora), PHP code follows PSR-1, but not all PSR-2 (which isn't a K&R style).

Proposal to adopt llvm style as C code style

So, to be coherent, I suggest we use use llvm as code style, so we can get a K&R/1TBS style.

It also introduces sensible pointer/reference symbols positions helping to avoid mistakes like char* foo, bar: the llvm style will rewrite that as char *foo, bar, allowing immediately to see something is wrong.

The only restriction I would bring is the spacing, they indent as 2 spaces, we'll use 4 to be coherent with PEP-8 and the rest of the languages.

Tools to reformat automatically and enforce this style

Furthermore, clang provides a good linter, clang-format, not only to detect style issues, but also able to reformat the code with this style.

We can integrate it with Arcanist, and so avoid to waste time in reviews to point style issues, as it would have already be arc lint (called by arc diff). Currently, it requires to install a plug-in for Arcanist, but linter author and Phabricator project both agree to directly integrate it to Arcanist.

This also helps to gain time. For example, it allows to correctly transform a long line into a nicely aligned block, cut after 80 characters:

static int mq_command(ClientData clientData, Tcl_Interp *tclInterpreter,
                      int argc, char **argv) {
    ...
}

Here a configuration file for clang-format with the style I suggest:

Event Timeline

dereckson raised the priority of this task from to Normal.
dereckson updated the task description. (Show Details)
dereckson added a project: architecture.
dereckson added subscribers: dereckson, xcombelle.
dereckson added subscribers: rama, fauve, Sandlayth.

Adding people having write some code in C in their life as bug CCs.

For the remaining, we should also document an cross-languages set of recommendations, at least for C family.

  • Keep in mind your goal is to write simple, clear and concise code
  • Avoid use of oneliner: you're not preparing a puzzle but a codebase with maintain and support goals
  • Avoid use of exotic constructs, like a ternary operator
  • Divide your code in small functions, which cater for one task

Where is the llvm C code style guide ?

Le llvm style guide, c'est un style guide pour c++ par pour le c ?

Le llvm style guide, c'est un style guide pour c++ par pour le c ?

As long as we're speaking about the indent/spaces/brackets details, these are common for several languages.

If we want to cater for C specific details, we should perhaps write about:

  • headers
  • prototypes
  • declarations
  • macros
  • enum
  • C90, C99 or C11?
    • variable-length arrays?
    • // comments?
    • generics macros?
    • initialize variable later in the function, at least for counters like in for (int i = 0 ; i < n ; i++)?

Language (LanguageKind)
Language, this format style is targeted at.

Possible values:

LK_None (in configuration: None) Do not use.
LK_Cpp (in configuration: Cpp) Should be used for C, C++, ObjectiveC, ObjectiveC++.
LK_Java (in configuration: Java) Should be used for Java.
LK_JavaScript (in configuration: JavaScript) Should be used for JavaScript.
LK_Proto (in configuration: Proto) Should be used for Protocol Buffers (https://developers.google.com/protocol-buffers/).