Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
private:codingstyle [2013/04/19 00:05] Patrick Wacker first statements taken place |
private:codingstyle [2013/04/19 15:07] (aktuell) Patrick Wacker dies und das |
||
---|---|---|---|
Zeile 9: | Zeile 9: | ||
< tab! | < tab! | ||
+ | |||
+ | ====== Version 1 ====== | ||
+ | short explanation | ||
+ | ################################################################################ | ||
====== Coding Style ====== | ====== Coding Style ====== | ||
- | ==== Indroduction ==== | + | ==== Introduction ==== |
- | This documents discribes the coding style I prefer in the most cases | + | This documents describes the coding style I prefer in the most cases |
and most other situations as well. | and most other situations as well. | ||
Zeile 22: | Zeile 26: | ||
=== Editing this document === | === Editing this document === | ||
- | The text for this docuemnt is written with the syntax that dokuwiki supports. | + | The text for this document is written with the syntax that dokuwiki supports. |
See https://www.dokuwiki.org for more details. | See https://www.dokuwiki.org for more details. | ||
- | But this document should be easy readable as plain text as well. So do not | + | But this document should be easily readable as plain text as well. So do not |
use any fancy looking html outputs. | use any fancy looking html outputs. | ||
Zeile 36: | Zeile 40: | ||
</code> | </code> | ||
- | each code expample must be intented with a tabulator! (not spaces!) | + | each code example must be indented with a tabulator! (not spaces!)\\ |
- | [This is automaticaly displayed as code examples!] | + | [This is automatically displayed as code examples!] |
Zeile 43: | Zeile 47: | ||
- | --------------------------------------------------------------------------+----- | ||
+ | ====== Version 2 ====== | ||
+ | mostly from: http://techbase.kde.org/Policies/Kdelibs_Coding_Style | ||
+ | ################################################################################ | ||
===== Coding style ===== | ===== Coding style ===== | ||
- | This documents discripes the coding style I prefer. Coding style is very | + | This documents describes the coding style I prefer. Coding style is very |
- | personal, and I won't force my views on onybody, but this is what goes for | + | personal, and I won't force my views on anybody, but this is what goes for |
anything that I have to be able to maintain, and I'd prefer it for most | anything that I have to be able to maintain, and I'd prefer it for most | ||
other things too. | other things too. | ||
Zeile 56: | Zeile 62: | ||
Please at least consider the points made here. | Please at least consider the points made here. | ||
- | First off, I'd suggest printing out a copy of the GNU coding standards, | ||
- | and NOT read it. Burn them, it's a great symbolic gesture. | ||
- | Anyway, here goes: | + | ==== Indentation ==== |
+ | |||
+ | * use tabs for indentation | ||
+ | * tabs are 8 characters, and thus indentations are also 8 characters. | ||
+ | |||
+ | ==== Variable declaration ==== | ||
+ | |||
+ | * Each new word in a variable name starts with a capital letter\\ (so-called camelCase) | ||
+ | * Avoid abbreviations | ||
+ | * Take usefull names. No short names, except: | ||
+ | * singe character variable names can denote counters and temporary\\ variables whose purpose is obvious | ||
+ | * Variables and functions start with a lowercase letter | ||
+ | |||
+ | ==== Whitespace ==== | ||
+ | |||
+ | * Use blank lines to group statements | ||
+ | * Use only one empty line | ||
+ | * Use one space after each keyword | ||
+ | * For pointers or references, use a single space before '*' or '&', but not after | ||
+ | * No space after a cast | ||
+ | |||
+ | ==== Braces ==== | ||
+ | |||
+ | As a base rule, the left curly brace goes in the same line as the start of the statement. | ||
+ | |||
+ | Example: | ||
+ | // wrong | ||
+ | if (true) | ||
+ | { | ||
+ | } | ||
+ | |||
+ | // correct | ||
+ | if (true) { | ||
+ | } | ||
+ | |||
+ | Exception: Function implemnetations, class, struct and namespace declarations always have the opening brace in the start of a line. | ||
+ | |||
+ | Example: | ||
+ | void debug(int i) | ||
+ | { | ||
+ | qDebug("foo: %i", i); | ||
+ | } | ||
+ | |||
+ | class Debug | ||
+ | { | ||
+ | }; | ||
+ | |||
+ | |||
+ | Do not unnecessarily use braces where a single statement will do. | ||
+ | |||
+ | if (condition) | ||
+ | action(); | ||
+ | |||
+ | and | ||
+ | |||
+ | if (condition) | ||
+ | do_this(); | ||
+ | else | ||
+ | do_that(); | ||
+ | |||
+ | This does not apply if one branch of a conditional statement is a | ||
+ | single statement. Use braces in both branches. | ||
+ | |||
+ | if (condition) { | ||
+ | do_this(); | ||
+ | do_that(); | ||
+ | } else { | ||
+ | otherwise(); | ||
+ | } | ||
+ | |||
+ | |||
+ | ==== Switch statements ==== | ||
+ | |||
+ | Case labels are on the same column as the switch | ||
+ | |||
+ | switch (myEnum) { | ||
+ | case Value1: | ||
+ | doSomething(); | ||
+ | break; | ||
+ | case Value2: | ||
+ | doSomethingElse(); | ||
+ | /* fall through */ | ||
+ | default: | ||
+ | defaultHandling(); | ||
+ | break; | ||
+ | } | ||
+ | |||
+ | ==== Line breaks ==== | ||
+ | |||
+ | Try to keep lines shorter than 80 characters, insert line breaks as necessary. | ||
+ | |||
+ | Long strings are as well broken into shorter strings. The exception to this | ||
+ | is where exceeding 80 columns significantly increases readability and does | ||
+ | not hide information. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Version 3 ====== | ||
+ | mostly from linux kernel | ||
+ | ################################################################################ | ||
+ | |||
+ | |||
+ | ===== Coding style ===== | ||
+ | |||
+ | This documents describes the coding style I prefer. Coding style is very | ||
+ | personal, and I won't force my views on anybody, but this is what goes for | ||
+ | anything that I have to be able to maintain, and I'd prefer it for most | ||
+ | other things too. | ||
+ | |||
+ | Please at least consider the points made here. | ||
Zeile 106: | Zeile 221: | ||
something to hide: | something to hide: | ||
- | if (condition) do_this; | + | if (condition) do_this; |
- | do_something_everytime; | + | do_something_everytime; |
- | Don't put multiple assignments on a single line either. Kernel coding style | + | Don't put multiple assignments on a single line either. Avoid |
- | is super simple. Avoid tricky expressions. | + | tricky expressions. |
- | Outside of comments, documentation and except in Kconfig, spaces are never | + | Outside of comments and documentation, spaces are never used for |
- | used for indentation, and the above example is deliberately broken. | + | indentation, and the above example is deliberately broken. |
Get a decent editor and don't leave whitespace at the end of lines. | Get a decent editor and don't leave whitespace at the end of lines. | ||
Zeile 121: | Zeile 236: | ||
+ | ==== Breaking long lines and strings ==== | ||
+ | Coding style is all about readability and maintainability using commonly | ||
+ | available tools. | ||
+ | The limit on the length of lines is 80 columns but this is not a strong | ||
+ | limit. | ||
+ | Statements longer than 80 columns should be broken into sensible chunks. | ||
+ | Descendants are always substantially shorter than the parent and are placed | ||
+ | aligned to the opening brace of the previous line. The same applies to | ||
+ | function headers with a long argument list. Long strings are as well broken | ||
+ | into shorter strings. The exception to this is where exceeding 80 columns | ||
+ | significantly increases readability and does not hide information. | ||
+ | void fun(int a, int b, int c) | ||
+ | { | ||
+ | if (condition) | ||
+ | qWarning("This is a long Warning message with 3 " | ||
+ | "parameters a: %u b: %u and c: %u", | ||
+ | a, b, c); | ||
+ | else | ||
+ | next_statement; | ||
+ | } | ||
+ | |||
+ | ==== Placing Braces and Spaces ==== | ||
+ | The other issue that always comes up in C styling is the placement of | ||
+ | braces. Unlike the indent size, there are few technical reasons to | ||
+ | choose one placement strategy over the other, but the preferred way, as | ||
+ | shown to us by the prophets Kernighan and Ritchie, is to put the opening | ||
+ | brace last on the line, and put the closing brace first, thusly: | ||
+ | if (x is true) { | ||
+ | we do y | ||
+ | } | ||
+ | This applies to all non-function statement blocks (if, switch, for, | ||
+ | while, do). E.g.: | ||
+ | |||
+ | switch (action) { | ||
+ | case ADD: | ||
+ | return "add"; | ||
+ | case REMOVE: | ||
+ | return "remove"; | ||
+ | case CHANGE: | ||
+ | return "change"; | ||
+ | default: | ||
+ | return NULL; | ||
+ | } | ||
+ | |||
+ | However, there is one special case, namely functions: they have the | ||
+ | opening brace at the beginning of the next line, thus: | ||
+ | |||
+ | int function(int x) | ||
+ | { | ||
+ | body of function | ||
+ | } | ||
+ | |||
+ | Heretic people all over the world have claimed that this inconsistency | ||
+ | is ... well ... inconsistent, but all right-thinking people know that | ||
+ | (a) K&R are __right__ and (b) K&R are right. Besides, functions are | ||
+ | special anyway (you can't nest them in C/C++). | ||
+ | |||
+ | Note that the closing brace is empty on a line of its own, __except__ in | ||
+ | the cases where it is followed by a continuation of the same statement, | ||
+ | ie a "while" in a do-statement or an "else" in an if-statement, like | ||
+ | this: | ||
+ | |||
+ | do { | ||
+ | body of do-loop | ||
+ | } while (condition); | ||
+ | |||
+ | and | ||
+ | |||
+ | if (x == y) { | ||
+ | .. | ||
+ | } else if (x > y) { | ||
+ | ... | ||
+ | } else { | ||
+ | .... | ||
+ | } | ||
+ | |||
+ | Rationale: K&R. | ||
+ | |||
+ | Also, note that this brace-placement also minimizes the number of empty | ||
+ | (or almost empty) lines, without any loss of readability. Thus, as the | ||
+ | supply of new-lines on your screen is not a renewable resource, you have | ||
+ | more empty lines to put comments on. | ||
+ | |||
+ | Do not unnecessarily use braces where a single statement will do. | ||
+ | |||
+ | if (condition) | ||
+ | action(); | ||
+ | |||
+ | and | ||
+ | |||
+ | if (condition) | ||
+ | do_this(); | ||
+ | else | ||
+ | do_that(); | ||
+ | |||
+ | This does not apply if one branch of a conditional statement is not a | ||
+ | single statement. Use braces in both branches. | ||
+ | |||
+ | if (condition) { | ||
+ | do_this(); | ||
+ | do_that(); | ||
+ | } else { | ||
+ | otherwise(); | ||
+ | } | ||
+ | |||
+ | |||
+ | === Spaces === | ||
+ | |||
+ | Use of spaces depends (mostly) on function-versus-keyword usage. Use a space | ||
+ | after (most) keywords. The notable exceptions are sizeof, typeof, alignof, | ||
+ | and __attribute__, which look somewhat like functions (and are usually used | ||
+ | with parentheses in Linux, although they are not required in the language, | ||
+ | as in: "sizeof info" after "struct fileinfo info;" is declared). | ||
+ | |||
+ | So use a space after these keywords: | ||
+ | |||
+ | if, switch, case, for, do, while | ||
+ | |||
+ | but not with sizeof, typeof, alignof. E.g.: | ||
+ | |||
+ | s = sizeof(struct file); | ||
+ | |||
+ | Do not add spaces around (inside) parenthesized expressions. | ||
+ | This example is **bad**: | ||
+ | |||
+ | s = sizeof( struct file ); | ||
+ | |||
+ | When declaring pointer data or a function that returns a pointer type, the | ||
+ | preferred use of '*' is adjacent to the data name or function name and not | ||
+ | adjacent to the type name. Examples: | ||
+ | |||
+ | char *banner; | ||
+ | unsigned long long memparse(char *ptr, char **retptr); | ||
+ | char *match_strdup(substring_t *s); | ||
+ | |||
+ | Use one space around (on each side of) most binary and ternary operators, | ||
+ | such as any of these: | ||
+ | = + - < > * / % | & ^ <= >= == != ? : | ||
+ | |||
+ | but no space after unary operators: | ||
+ | & * + - ~ ! sizeof typeof alignof defined | ||
+ | |||
+ | no space before the postfix increment & decrement unary operators: | ||
+ | ++ -- | ||
+ | |||
+ | no space after the prefix increment & decrement unary operators: | ||
+ | ++ -- | ||
+ | |||
+ | and no space around the '.' and "->" structure member operators. | ||
+ | |||
+ | Do not leave trailing whitespace at the ends of lines. Some editors with | ||
+ | "smart" indentation will insert whitespace at the beginning of new lines as | ||
+ | appropriate, so you can start typing the next line of code right away. | ||
+ | However, some such editors do not remove the whitespace if you end up not | ||
+ | putting a line of code there, such as if you leave a blank line. As a result, | ||
+ | you end up with lines containing trailing whitespace. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | --------------------------------------------------------------------------+----- | ||
Zeile 143: | Zeile 424: | ||
+ | ====== Version 4 ====== | ||
+ | original linux kernel | ||
+ | ################################################################################ | ||