Skip to content
This repository has been archived by the owner on Dec 12, 2019. It is now read-only.

coding style

Jump to bottom
Grimmer Kang edited this page Apr 5, 2017 · 10 revisions

Coding Standard [Draft]

Python

Use PEP 8.

JavaScript

Use Airbnb JavaScript Style Guide, need check if it is compatible with Qooxdoo.

Please use ESLint (http://eslint.org/) as your linter tool. You can find its plugins for your IDE/Editors.

C++

The plan is to partial follow Google C++ Style Guide and use its convenient tool: https://google.github.io/styleguide/cppguide.html

Modification

  1. Except some below items, use the Formatting rules from Google’s c++ Style guide e.g. 
    for (int i = 0; i < kSomeNumber; ++i) {

}

bool result = DoSomething(averyveryveryverylongargument1,
                      argument2, argument3);
  2. Regarding name convention, use the existing style (will complement later), not Google's.
  3. Use curly braces for single conditional statements. e.g. 
    if (true) {
    x++;
}
  4. Use 4 space for indentation. Not google's 2 spaces.

Policy of new codes and existing codes

  1. New code. Just use consistent coding style, not diverge anymore.
  2. Don't change only 1 line or partial of the existing function/class to fit the new style. Also, only when you need to modify the existing code to fix a bug, then you can refactor the whole function/class, otherwise just keep the existing codes.

Google C++ Style Guide - Formatting

Spaces vs. Tabs.

https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs

Use only spaces, and indent 2 spaces at a time.

We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

Function Declarations and Definitions

https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions

  • There is never a space between the parentheses and the parameters.
  • The open curly brace is always on the end of the last line of the function declaration, not the start of the next line.
  • There should be a space between the close parenthesis and the open curly brace.
  • Default indentation is 2 spaces.

Conditionals

https://google.github.io/styleguide/cppguide.html#Conditionals

Note that in all cases you must have a space between the if and the open parenthesis. You must also have a space between the close parenthesis and the curly brace, if you're using one.

if (condition) {  // no spaces inside parentheses
  ...  // 2 space indent.
} else if (...) {  // The else goes on the same line as the closing brace.
  ...
} else {
  ...
}

In general, curly braces are not required for single-line statements, but they are allowed if you like them; conditional or loop statements with complex conditions or statements may be more readable with curly braces. Some projects require that an if must always always have an accompanying brace.

if (condition)
  DoSomething();  // 2 space indent.

if (condition) {
  DoSomething();  // 2 space indent.
}

Loops

https://google.github.io/styleguide/cppguide.html#Loops_and_Switch_Statements

for (int i = 0; i < kSomeNumber; ++i)

Function Calls

https://google.github.io/styleguide/cppguide.html#Function_Calls

bool result = DoSomething(argument1, argument2, argument3);

bool result = DoSomething(averyveryveryverylongargument1,
                          argument2, argument3);

if (...) {
  ...
  ...
  if (...) {
    bool result = DoSomething(
        argument1, argument2,  // 4 space indent
        argument3, argument4);
    ...
  }

Boolean Expressions

if (this_one_thing > this_other_thing &&
    a_third_thing == a_fourth_thing &&
    yet_another && last_one) {
  ...
}

Google C++ Style Guide - Naming (just a reference, use our existing naming style)

https://google.github.io/styleguide/cppguide.html#Naming

General Naming Rules

https://google.github.io/styleguide/cppguide.html#General_Naming_Rules

Names should be descriptive; avoid abbreviation.

int price_count_reader;    // No abbreviation.
int num_errors;            // "num" is a widespread convention.
int num_dns_connections;   // Most people know what "DNS" stands for.

int n;                     // Meaningless.
int nerr;                  // Ambiguous abbreviation.
int n_comp_conns;          // Ambiguous abbreviation.
int wgc_connections;       // Only your group knows what this stands for.
int pc_reader;             // Lots of things can be abbreviated "pc".
int cstmr_id;              // Deletes internal letters.

File Names

https://google.github.io/styleguide/cppguide.html#File_Names

Filenames should be all lowercase and can include underscores (_) or dashes (-). Follow the convention that your project uses. If there is no consistent local pattern to follow, prefer "_".

Examples of acceptable file names:

my_useful_class.cc
my-useful-class.cc
myusefulclass.cc
myusefulclass_test.cc // _unittest and _regtest are deprecated.

Variable Names

https://google.github.io/styleguide/cppguide.html#Variable_Names)

The names of variables (including function parameters) and data members are all lowercase, with underscores between words. Data members of classes (but not structs) additionally have trailing underscores. For instance: a_local_variable, a_struct_data_member, a_class_data_member_

Common Variable names

For example:

string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.
string tableName;   // Bad - mixed case.

Class Data Members

Data members of classes, both static and non-static, are named like ordinary nonmember variables, but with a trailing underscore.

class TableInfo {
  ...
 private:
  string table_name_;  // OK - underscore at end.
  string tablename_;   // OK.
  static Pool<TableInfo>* pool_;  // OK.
};

Function Names

https://google.github.io/styleguide/cppguide.html#Function_Names

Regular functions have mixed case; accessors and mutators may be named like variables.

Ordinarily, functions should start with a capital letter and have a capital letter for each new word (a.k.a. "Camel Case" or "Pascal case"). Such names should not have underscores. Prefer to capitalize acronyms as single words (i.e. StartRpc(), not StartRPC()).

AddTableEntry()
DeleteUrl()
OpenFileOrDie()

(The same naming rule applies to class- and namespace-scope constants that are exposed as part of an API and that are intended to look like functions, because the fact that they're objects rather than functions is an unimportant implementation detail.)

Accessors and mutators (get and set functions) may be named like variables. These often correspond to actual member variables, but this is not required. For example, int count() and void set_count(int count).

Reference - LLVM:

http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly

While this document may provide guidance for some mechanical formatting issues, whitespace, or other “microscopic details”, these are not fixed standards. Always follow the golden rule:

If you are extending, enhancing, or bug fixing already implemented code, use the style that is already being used so that the source is uniform and easy to follow.

Summary:

  1. Function name (lower camel case)
  2. Variable (upper camel case/Pascal)

Reference - C++ Core Guidelines

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

if (condition)
{

}

NL.10: Avoid CamelCase

Reason

The use of underscores to separate parts of a name is the original C and C++ style and used in the C++ standard library. If you prefer CamelCase, you have to choose among different flavors of camelCase.

Note

This rule is a default to use only if you have a choice. Often, you don’t have a choice and must follow an established style for consistency. The need for consistency beats personal taste.

Discuss Items

Google and C++ Core both uses ISO standard-library style (lower case and underscore)

  1. Indentation: 2 (new style) vs 4.
  2. File names. lower case and underscore vs upper camel case
  3. Variable Names. lower case and underscore + member variable with suffix"_" vs lower camel case?

cpplint and other formatter tools

Qt Creator http://doc.qt.io/qtcreator/creator-beautifier.html

  1. choose Artistic Style tool (seems not good enough, only google indent style) use its style=google http://astyle.sourceforge.net/astyle.html
  2. ClangFormat, https://clang.llvm.org/docs/ClangFormat.html, can base on google style to customize

Atom https://atom.io/packages/linter-cpplint

emacs https://github.com/senda-akiha/flymake-google-cpplint https://www.douban.com/note/595331980/ http://blog.csdn.net/wangell/article/details/39780233

vim https://github.com/funorpain/vim-cpplint https://github.com/vim-syntastic/syntastic/wiki/C--:---cpplint

Xcode: cpplint.py http://stackoverflow.com/questions/17164364/xcode-external-tools-cpplint

cpplink + Git hook https://blog.brickgao.com/2016/10/11/ccplint-git-hook/ https://gist.github.com/brickgao/fb359764d46f9c96dd3af885e94b0bab https://github.com/jubatus/jubatus/blob/master/tools/codestyle/pre-commit http://qiita.com/janus_wel/items/cfc6914d6b7b8bf185b6

Clone this wiki locally