Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

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
 +################################################################################​
  
  

Zuletzt angesehen:

Projektwerkzeuge